LogoLogo
Contribute to InnerSource PatternsJoin the community
🇯🇵 日本語
🇯🇵 日本語
  • イントロダクション
  • 目次
  • パターンの一覧
  • この本へのコントリビューション
  • パターン
    • 30日の保証期間
    • RFCを用いたチーム横断的な意思決定の透明化
    • イシュートラッカーの使い方を多様化する
    • インナーソースポータル
    • インナーソースライセンス
    • ギグマーケットプレイス
    • クロスチームプロジェクト評価
    • コアチーム
    • コミュニケーションツーリング
    • コントラクトコントリビューター
    • コントリビューションの功労を称える
    • サービス対ライブラリ
    • スタンダード・ベース・ドキュメンテーション
    • トラステッドコミッター
    • リポジトリアクティビティスコア
    • レビュー委員会
    • 共通要件
    • 基本原則ガイダンスの文書化
    • 実験として始める
    • 成熟度モデル
    • 持続可能な成長のためのエクステンション
    • 正式なコミュニティリーダー
  • 付録
    • パターンテンプレート
    • その他
      • README テンプレート
      • CONTRIBUTING テンプレート
  • リソース
    • GitHub
    • InnerSource Commons
GitBook提供
このページ内
  • Title
  • Patlet
  • 問題
  • 状況
  • 組織に働く力学
  • ソリューション
  • 結果の状況
  • その他の情報
  • 事例
  • ステータス
  • 著者
  • 謝辞
  • その他の呼び方
  • 翻訳の履歴

役に立ちましたか?

GitHubで編集
PDFとしてエクスポート
  1. パターン

サービス対ライブラリ

Title

サービス対ライブラリ

Patlet

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

問題

チームがDevOps環境で作業しているとき、開発者は機能をエンドツーエンドで担当することになります。顧客からデプロイメント、メンテナンス、サポートに至るまでです。このことは、チームの境界を越えて作業する際に課題となります。エスカレーションチェーンは、どちらのチームでも発生するエラーに対して同じではないかもしれません。ソースコードとデプロイメントを結合すると、エラーが発生した場合に誰がオンコールサポートの責任を負うのかという疑問がチームに残ります。その結果、要件に大きな重複がある場合でも、チームは協力し合うことに消極的になってしまいます。

状況

  • チームはマイクロサービス環境で働いています。

  • チームは完全に機能する DevOps チームによって編成されています。各チームは、メンテナンス、オンコール、カスタマーサポートを含むエンドツーエンドのコントリビューションに責任があります。

  • あるチームは、他のチームが構築した既存のサービスとよく似たサービスを下流の顧客に提供することを任務としています。

組織に働く力学

  • 組織的なエスカレーション経路は、各チームで異なる可能性があります。

  • 各チームのメンバーは、自分たちの顧客に影響を与えないエラーのオンコールサポートに応じないことがあります。

  • 同じ種類のエラーでも、チームや顧客との関係によって SLA の定義が異なるため、深刻度レベルが異なる場合があります。

  • チームによって、セキュリティや規制の制約が異なる場合があります。

ソリューション

ソースコードとデプロイメントの責任を切り離します。両チームは、重複と相乗効果がある場所を正確に特定するために働きます。

共有されたソースコードのみが、責任を共有したインナーソースプロジェクトの一部として保持されます。共有ソースは、すべてのテストコード(可能であれば統合テストを含む)と、コントリビューションの検証を容易にするために可能な限りCIパイプラインを含むという点で、首尾一貫している必要があります。

設定とデプロイのパイプラインを、実際のビジネスロジックから切り離します。 共有したチーム用に、サービスの2つめのデプロイメントを確立します。

共通基盤を、両チームで使用するライブラリとして扱い、コードの所有権を共有します。

デプロイメント設定をインナーソースポートフォリオの別プロジェクトとして含めることで、チームが議論/共同作業を行ったり、新しいチームがそれをコピーしたりすることができるようになります。

結果の状況

チームは積極的に協力し、ビジネスロジックを実装する作業を共有することで利益を得ることができます。

ある環境で動作するように特別に構築されたサービスが、特定のビジネス要件に基づき、より一般的なソリューションに変換されます。

両チームは、それぞれのエスカレーションポリシーと展開設定を知ることができ、自分たちの設定に対する改善点を見出すことができる可能性があります。

共有されたソースコードに変更が必要な可能性が高まり、実装を改良、改善、最適化する機会がより頻繁に発生するようになる。

リリースのパッケージング、遠隔測定、ヘルス/レディネス エンドポイントなど、運用の標準化を段階的に進めることができるようになります。

その他の情報

事例

  • ユーロスペース AG

ステータス

  • Structured

著者

  • Isabel Drost-Fromm

  • Rob Tuley

謝辞

Tobias Gesellchenさん、Europace AGの内部レビューをありがとうございました。

その他の呼び方

サービス対ライブラリ: インナーデプロイメントではなくインナーソース

翻訳の履歴

  • 2023-06-18 - 最終更新

前へコントリビューションの功労を称える次へスタンダード・ベース・ドキュメンテーション

最終更新 1 年前

役に立ちましたか?

このパターンに関連するものとして、上記を解決するために異なるアプローチをとる パターンがあります。

Flutter Entertainment: には、チーム横断的にコントリビュートする共有コードの"サービスリポジトリ"と、共有リリース成果物をビルドして公開するためのCIパイプラインがあります。各チームは、独自のデプロイメントを定義する"デプロイメント設定"リポジトリを持っています。これは、さまざまな規制要件、サービスおよびインシデント管理の実践、ビジネスの各領域におけるインフラストラクチャのスキルセットによって異なる運用がされています。

2022-06-06 - 翻訳

2022-06-13 - レビュー

30日の保証期間
Flutter インナーソースの応用
Yuki Hattori
@kanazawazawa