今日、多くの企業は、ミラーリング、プロキシ、およびキャッシングを使用している場合でも、外部リポジトリパッケージの構成を直接管理する機能なしで運営されています。これは、実行環境が絶えず変化しているという事実につながります。特に、ドッカーイメージの構成は、本番環境で必要とされるよりも頻繁に変更されます。
外部の依存関係に含まれる不要な変更が、開発中の製品の構成に影響を与える可能性がある場合があります。これは、製品の認証時に特に当てはまります。その結果、認証の遅延、夜間テストと統合テストの失敗、ホットフィックスをロールする際のオンプレミスプロダクション（組織独自のリソースにあるプロダクション環境）の故障などが発生します。新しい記事では、これらの問題を回避するためのアプローチについて説明しました。
達成したいこと
アプローチの説明に進む前に、解決したいタスクについていくつか説明します。
- リリース内の外部パッケージの構成を完全に制御できます（予測可能性）。
- 最小限の追加テスト（速度）でホットフィックスを迅速にロールアウトできるように、外部リポジトリの構成を修正します。
- 製品のQAスタンドに、再現性、予測性、固定環境（再現性）を提供します。
- 外部通信チャネルの存在からの独立性（自律性）。
- 障害が発生した場合（障害耐性）、公式リポジトリに即座に切り替えます。
- アセンブリパイプライン内の外部リポジトリのキーの検証が保証されています（信頼）。
- そして最も重要なことは、外部パッケージの構成に対する管理と制御を製品チームとリリースマネージャーの手に移すことです（自己管理）。
機能構築ライフサイクル分析
私たちのアプローチは、リリースまたは機能のために、特定の日付の外部リポジトリの構成を修正する問題を解決します。次の図は、リリース、機能ビルド、およびホットフィックスのライフサイクルの管理を示しています。
例として、DebianStretch条件付きリポジトリを取り上げましょう。このアプローチは、Docker、SaltStackなどのリポジトリに適用できます。日付T1、T2、およびT3のタイムラインに3つのスライスが記録されました。
| T1 | T2 | T3 | |
|---|---|---|---|
| ストレッチ | 20200305 | 20200420 | 20200615 |
| 機能1 | 20200304 | 20200304 | 20200501 |
| 機能2 | 20200304 | 20200304 | 20200601 |
| 機能3 | 20200301 | 20200406 | 20200406 |
Feature1、Feature2、およびFeature3ディストリビューションを構築するための外部DebianStretchリポジトリの内容を表にまとめました。表から、外部リポジトリの構成が各ブランチによって個別に制御されていることがわかります。私たちは、Debian Stretchのマスターブランチに毎日コミットし、各スライスにYYYYMMDD形式でタグを付けることに同意しました。たとえば、2020年3月4日のスライスの場合は2020304です。この表は、3つの異なる時点での各ブランチでの配布に使用される外部リポジトリのスナップショットと、DebianStretchのウィザードの構成をまとめたものです。各機能または各リリースのチームは、その裁量で、開発サイクルに従って外部リポジトリの構成を更新します。
例としてFeature1を使用します。製品チームは新しい機能の開発を開始し、構成ファイル内の20200228の時点で外部リポジトリの構成を修正します（上の図を参照）。
20200228への切り替え
deb http://repository.co/debian-stretch-20200228 stretch main contrib non-free
開発中、新しいパッケージが出現したため、パッケージデータベースを日付20200304に更新する必要があります。作業リポジトリを目的の日付に切り替えます。
20200304
deb http://repository.co/debian-stretch-20200304 stretch main contrib non-free
への切り替え次に、20200501の日付へのパッケージベースの別の切り替えが行われます。20200501への
切り替え
deb http://repository.co/debian-stretch-20200501 stretch main contrib non-free
ここでタイムスライスを描画すると、2020年3月4日に「凍結」されたパッケージベースでT1およびT2Feature1の開発が進行していることがわかります。また、T3カットでは、2020年5月1日の新しいパッケージベースの開発がすでに進行中です。
製品のマルチリリース依存関係管理
次に、いくつかのアクティブな製品リリースの依存関係管理を見てみましょう。サポートには、2.5、2.6、2.7の3つのリリースがあります。
この表には、リポジトリのスナップショットが作成されたリリースと日付の対応が示されています。これは、ディストリビューションの特定のバージョンを構築するために使用された外部リポジトリの構成のスナップショットを示しています。
| リリース | 組成 |
|---|---|
| 2.5.128、2.5.135、2.5.207 | 20200301 |
| 2.6.201、2.6.215、2.6.315 | 20200301 |
| 2.7.210、2.7.217、2.7.305 | 20200404 |
YYYYMMDDの日付でスライスに名前を付ける代わりに、<ProjectName.ReleaseVersion>（製品のrelease_name.release_version、たとえばname.2.2）または<ProjectName-FeatureNumber>（たとえば3の機能番号を追加）の形式でタグの名前を付けることも使用します。
20200301現在の2.5のスナップショット
deb http://repository.co/debian-stretch-projectname-2.5 stretch main contrib non-free # 20200301
したがって、リリース2.5の開発中に、チームは20200301現在の依存リポジトリの構成を修正します。4月のどこかで、チームは新しい2.6リリースを開始し、2.5からの外部リポジトリパッケージの構成を使用することを決定します。 2.5スナップショットから新しい2.6スナップショットを作成します。将来的には、2.5リリースと2.6リリースのリポジトリは簡単に分岐する可能性があります。 2.6用にdebian-stretch-projectname-2.6タグを作成しました。
20200301現在の2.6のスナップショット
deb http://repository.co/debian-stretch-projectname-2.6 stretch main contrib non-free # 20200301
リリース2.7の場合、チームはマスターブランチ（元のリポジトリの毎日のスナップショット）から開発を開始できます。
20200404現在の2.7のスナップショット
deb http://repository.co/debian-stretch-projectname-2.7 stretch main contrib non-free # 20200404
複数製品の依存関係管理
リリースサイクルが異なる2つの製品と、独自の製品チームであるStealthとInfinitiの例を使用して、複数製品の依存関係管理を見てみましょう。
何がいつ起こるかを表にコメントしましょう。
| 製品 | リリース | 組成 |
|---|---|---|
| ステルス2.2 | r2.2.124 | 20200301 |
| ステルス2.2 | r2.2.131、r2.2.162 | 20200305 |
| infiniti4.0 | r4.0.235、r4.0.241 | 20200303 |
| infiniti4.0 | r4.0.250 | 20200308 |
1.ステルスプロジェクトのバージョン2.2の開発を2020年3月1日に開始します。これにより、現在の日付のパッケージデータベースの構成のスナップショットが作成されました。リリース2.2.124のリリースは、20200301からの外部リポジトリ のパッケージベースで行われます。
ステルス2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200301
2. 5日目に、パッケージベースが更新されます。 debian-stretch-stealth-2.2作業リポジトリは即座に希望の日付に切り替わり、リリース2.2.131および2.2.162のリリースは、20200305からの外部リポジトリパッケージで行われます。環境で追加の操作を行わなくても、製品の100500マイクロサービスすべてがアセンブリパイプライン20200305で新しい環境をすぐに受け取りました。 ..。
ステルス2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200305
3.三日目と並行して、インフィニティバージョンの開発4.0プロジェクトが開始され、日20200303のためのリポジトリのスライスはそれのために作成されます。バージョン4.0.235と4.0.241が20200303.のための外部リポジトリのパッケージでリリースされている
インフィニティ4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200303
バージョン4.0.241のリリース後4、チームリポジトリの構成を20200308に更新し、外部パッケージの新しい構成で新しいリリースをリリースすることを決定します。バージョン4.0.250は20200308.用のパッケージバンドルでリリースされた
インフィニティ4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200308
リポジトリの状態を切り替えるための2つのオプションにより、開発プロセスに便利なアプローチを選択できます。最初のケースでは、特定の日付のリポジトリのスナップショットを指定することにより、目的の状態に切り替えます。2番目のケースでは、マルチコンポーネント製品の場合、名前付きスライスを使用して、目的の日付に移動します。このメカニズムは、100500のすべての製品コンポーネントで1回限りのカットオフ切り替えを提供します。
各外部リポジトリのスライスは個別のDockerコンテナで管理するため、事故が発生した場合はいつでも特定のリポジトリを切り替えて外部ネットワークからダウンロードできます。
すべてのリポジトリのリストをダウンロードする
# For example
curl repository.co/info/sources.list | grep $(lsb_release -cs) > /etc/apt/sources.list外部リポジトリのスライスの自動作成
リポジトリは、GitLabスケジューラに従って毎晩更新されます。新しいリポジトリが追加されると、変更はサーバーに自動的に適用されます。
外部リポジトリの新しいスライスをコミットするときに、その証明書がチェックされ、保存されているものと異なる場合、更新は行われず、エラーメッセージが表示されます。
結果
- 認定のために配布キットの新しいバージョンを準備することは、もはや頭痛の種ではありません。認定期間中、ディストリビューションの構成を修正します。迅速に修正する必要がある場合は、環境の変化によるリリースされた修正プログラムのエラーが発生しない可能性が高くなります。
- すべての機能ビルドは、外部リポジトリの管理状態を取得します。
- HotfixのロールアウトとQA検証が加速され、予測可能で高速かつ成功した結果が得られます。
- Feature- , .
- .
Debianには、毎日のスナップショットと深いストレージ深度を備えた公式のsnapshot.debian.orgリソースがあることに注意してください。これは特定のタスクには十分です。
Aptlyの外部リポジトリの構成を管理するための優れたツールを提供してくれたSergeySmirnovとコミュニティに感謝します。私たちから-生産コンベヤーでこの便利なツールを使用するためのベストプラクティスへの小さな貢献。
次の記事では、ディストリビューションのISOイメージを準備するためのAptly + Simple-CDDバンドル、外部依存関係の管理を製品チームに委任すること、および外部依存関係を管理するプロセスでAptlyを使用する際の問題について説明します。
著者：Nikita Drachev、Alexander Pazdnikov、Timur Gilmullin