プロダクションシステムとしての開発パイプライン

開発パイプラインはプロダクションシステムである

ソフトウェア開発チームは、顧客向けのプロダクション障害を何よりも優先することが多いですが、一方で、自社の開発ツール、ビルドシステム、およびQA環境における障害は、二の次として扱うことが頻繁にあります。しかし、価値を提供する責任を負う開発者やテスターにとって、開発パイプラインはプロダクションシステムです。パイプラインが壊れると、チームのソフトウェア制作能力が停止し、組織内部における機能的なプロダクション障害を引き起こします。

開発パイプラインの構成要素を特定する

パイプラインをプロダクションシステムとして扱うためには、まず、顧客の要求から機能の提供に至るまでの移行を促進するすべての構成要素を特定する必要があります。これらのクリティカルパス上の構成要素には以下が含まれます：

  • Request Tracking: Issue報告および変更要求システム（例：GitHub Issues, Jira）。
  • Local Development Tools: IDE、ビルドツール（Gradle, Maven）、パッケージリポジトリ（npm, Maven Central）、ローカルデータベース、およびコンテナ。
  • Automation Infrastructure: JenkinsやGitHub ActionsなどのCI/CDツール。
  • Quality Gates: テストスイートおよびQAサーバー。プロダクションへのデプロイを妨げる、失敗するテストスイートやオフラインのQAサーバーは、すべて重大な障害点となります。

パイプラインの障害がデリバリーに与える影響

開発パイプラインのコアコンポーネントが故障すると、価値の提供が完全に停止します。コードがコンパイルできなかったり、テストが実行できなかったりする場合、チームは動作するソフトウェアを制作することができません。製造業において、これは組立ラインの故障に相当します。そこでは、待機中の労働力のコストが非常に高いため、ダウンタイムを最小限に抑えるために広範なプロセスやSLAが用いられています。

Infrastructure-as-Production

運用的な観点から見ると、「プロダクション」の定義は、テクノロジースタックを下るにつれて拡大します。プロダクト開発者は顧客向けのシステムをプロダクションと見なしますが、インフラおよび運用チームは、開発およびテスト環境をプロダクションとして扱う必要があります。なぜなら、それらの障害が数百人の開発者を麻痺させてしまうからです。

インフラ運用担当の私たちにとって、開発とテストは実際にはプロダクションでもあります... もし開発やテストを壊してしまうと、100人の開発者が仕事ができなくなり、悲鳴を上げ始めます。

反論とリスク管理

パイプラインをプロダクションとして扱うことは緊急性を高めますが、同時に、管理すべき特定のトレードオフとリスクも導入します。

優先順位付けのジレンマ

一部の人々は、「プロダクション」というラベルは用語の誤用であると主張しており、壊れたIDEやビルドツールはプロダクション障害ではなく「開発システムの障害」であると示唆しています。主な批判は、パイプラインの修正の緊急性は、一律の「総員出動」ポリシーではなく、費用対効果分析の対象となるべきであるという点です。例えば、週末のパイプライン障害は、顧客向けの障害と同じ即時対応を必要としないかもしれません。

パイプラインからホットフィックスを切り離す

パイプラインをプロダクションとして扱うチームにとって、重要なアーキテクチャ上の要件は、緊急のホットフィックスのために標準的なパイプラインをバイパスする能力を持つことです。もし開発パイプラインが壊れている場合でも、チームは顧客向けのプロダクションシステムを復旧させることができなければなりません。

プロダクションを修正する必要があるときに開発パイプラインが壊れている場合に備えて、開発パイプラインをバイパスしてコードにホットフィックスをデプロイする方法を持っておくべきです。

パイプラインのセキュリティと書き込み権限

パイプラインをプロダクションとして扱うことは、パイプラインの権限の監査も必要とします。もしデプロイツールがプロダクションディレクトリに対して無制限の書き込みおよび削除アクセス権を持っている場合、パイプラインの設定ミスは、単にツールの障害を超えて、壊滅的なデータ損失につながる可能性があります。

パイプラインの安定性のための戦略

開発パイプラインが信頼できるプロダクションシステムであり続けることを確実にするため、チームはいくつかの安定化パターンを採用できます：

  • Dependency Pinning: Dockerイメージ、OSパッケージ、および言語固有の依存関係を固定（ピン留め）するためにツールを使用し、サードパーティの障害や「yanked」されたパッケージによってビルドが壊れるのを防ぎます。
  • Low-Dependency Rollbacks: CI/CDパイプラインに依存しないロールバックメカニズムを確立します。これにより、もしパイプライン自体が障害の原因である場合でも、システムを既知の正常な状態に戻すことができます。
  • Developer Experience (DevEx) Teams: 大規模な組織では、専用のDeveloper ExperienceまたはToolsチームが、パイプラインを第一級のプロダクトとして管理し、内部ツールへのSLAを提供することができます。

Sources