This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
As with all projects, the items mentioned on this page are subject to change or delay.
The development, release, and timing of any products, features, or functionality remain at the
sole discretion of GitLab Inc.
| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
このドキュメントは作業中のものであり、セルズの設計のごく初期の状態を表しています。重要な点は文書化されていませんが、将来的には追加される予定です。これはCellsの可能性のあるアーキテクチャの一つであり、どのアプローチを実装するか決める前に、代替案と比較検討するつもりです。この文書化は、このアプローチを選ばなかった理由を文書化できるよう、これを実装しないと決めた場合でも残しておきます。
セルスキーマの変更
独自のデータベースを所有する複数のセルを導入すると、Postgres と Elasticsearch のスキーマ変更のプロセスが複雑になります。今日、私たちはすでにゼロダウンタイムのデプロイに準拠した変更を行うよう注意する必要があります。例えば、カラムを削除する場合、3回に分けてデプロイする必要があります。post_migrate のようなツールがあり、この種の変更に必要なマージリクエストの回数を減らすのに役立っていますが、複数のRailsアプリケーションをデプロイして、常に異なるバージョンになるように対処する場合は複雑になります。この問題は、users 関連テーブルをすべての Cells で共有するという私たちの計画のような共有データベースの場合、特に厄介になります。
Cellsの主な利点は、GitLabの異なるバージョンで異なる顧客を実行できることでしょう。すべての顧客よりも先に私たち自身のCellを更新することで、現在のカナリアアーキテクチャよりもさらに柔軟性を持たせることができます。しかし、そうすることはスキーマの変更にさらに多くのバージョンの後方互換性サポートが必要になることを意味し、スキーマの変更に余分なステップが必要になるため開発者を遅らせる可能性があります。