サービス対ライブラリ
サービス対ライブラリ
DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うこ とが挙げられます。
チームがDevOps環境で作業しているとき、開発者は機能をエンドツーエンドで担当することになります。顧客からデプロイメント、メンテナンス、サポートに至るまでです。このことは、チームの境界を越えて作業する際に課題となります。エスカレーションチェーンは、どちらのチームでも発生するエラーに対して同じではないかもしれません。ソースコードとデプロイメントを結合すると、エラーが発生した場合に誰がオンコールサポートの責任を負うのかという疑問がチームに残ります。その結果、要件に大 きな重複がある場合でも、チームは協力し合うことに消極的になってしまいます。
- チームはマイクロサービス環境で働いています。
- チームは完全に機能する DevOps チームによって編成されています。各チームは、メンテナンス、オンコール、カスタマーサポートを含むエンドツーエンドのコントリビューションに責任があります。
- あるチームは、他の チームが構築した既存のサービスとよく似たサービスを下流の顧客に提供することを任務としています。
- 組織的なエスカレーション経路は、各チームで異なる可能性があります。
- 各チームのメンバーは、自分たちの顧客に影響を与えないエラーのオンコールサポートに応じないことがあります。
- 同じ種類のエラーでも、チームや 顧客との関係によって SLA の定義が異なるため、深刻度レベルが異なる場合があります。
- チームによって、セキュリティや規制の制約が異なる場合があります。
ソースコードとデプロイメントの責任を切り離します。両チームは、重複と相乗効果がある場所を正確に特定するために働きます。
共有されたソースコードのみが、責任を共有したインナーソースプロジェクトの一部として保持されます。共有ソースは、すべてのテストコード(可能であれば統合テストを含む)と、コントリビューションの検証を容易にするために可能な限りCIパイプラインを含むという点で、首尾一貫している必要があります。
設定とデプロイのパイプラインを、実際のビジネスロジックから切り離します。 共有したチーム用に、サービスの2つめのデプロイメントを確立します。
共通基盤を、両チームで使用するライブラリとして扱い、コードの所有権を共有します。
デプロイメント設定をインナーソースポートフォリオの別プロジェクトとして含めることで、チームが議論/共同作業を行ったり、新しいチームがそれをコピーしたりすることができるようになります。
チームは積極的に協力し、ビジネスロジックを実装する作業を共有することで利益を得ること ができます。
ある環境で動作するように特別に構築されたサービスが、特定のビジネス要件に基づき、より一般的なソリューションに変換されます。
両チームは、それぞれのエスカレーションポリシーと展開設定を知ることができ、自分たちの設定に対する改善点を見出すことができる可能性があります。
共有されたソースコードに変更が必要な可能性が高まり、実装を改良、改善、最適化する機会がより頻繁に発生するようになる。
リリースのパッケージング、遠隔測定、ヘルス/レディネス エンドポイントなど、運用の標準化を段階的に進めることができるようになります。
- ユーロスペース AG
- Flutter Entertainment: Flutter インナーソースの応用には、チーム横断的にコントリビュートする共有コードの"サービスリポジトリ"と、共有リリース成果物をビルドして公開するためのCIパイプラインがあります。各チームは、独自のデプロイメントを定義する"デプロイメント設定"リポジトリを持っています。これは、さまざまな規制要件、サービスおよびインシデント管理の実践、ビジネスの各領域におけるインフラストラクチャのスキルセットによって異なる運用がされています。
- Structured
- Isabel Drost-Fromm
- Rob Tuley
Tobias Gesellchenさん、Europace AGの内部レビューをありがとうございました。
サービス対ライブラリ: インナーデプロイメントではなくインナーソース