InnerSource Patterns: サービス対ライブラリ

概要
パターンの著者: Isabel Drost-Fromm / Rob Tuley
スピーカー/翻訳: Yuki Hattori | LinkedIn | Twitter | GitHub
YouTube: サービス対ライブラリ
Doc: サービス対ライブラリ

「InnerSource Patterns: サービス対ライブラリ」
* DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。
* 解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うことが挙げられます。

リンク
InnerSource Patterns: English 🇬🇧| 日本語 🇯🇵
Website: innersourcecommons.org
Slack: Invite Link | 🇯🇵#jp-general
Twitter: @InnerSourceJP (日本) | @InnerSourceOrg (公式)

Transcript

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