開発パイプラインは本番システムである

ソフトウェア開発者は、キャリアの早い段階で、本番環境での障害を修正することほど緊急性の高いものはないことを学びます。今すぐ手を止めろ！総出動だ！

しかし、同じレベルの緊急性が、開発ツール、ビルドシステム、QA環境、およびその他のソフトウェア開発パイプラインの問題に与えられることは多くありません。しかし、開発チームにとって、開発パイプラインは本番システムです。

ソフトウェア開発者の仕事は、会社に価値を提供することです。時には新機能の構築を意味し、時には顧客の本番システムに対する重大なバグの修正を意味します。しかし、ソフトウェア開発パイプラインで何かが壊れているとき、これらのどれも起こりえません。

コードがコンパイルできない場合、開発者は仕事ができず、チームはソフトウェアを生産していません。開発チームにとって、これは本番障害です。これを修正することは最優先事項であるべきです。

QAサーバーがダウンしている場合、テスターは仕事ができず、チームは動作するソフトウェアを生産していません。QAチームにとって、これは本番障害です。これを修正することは最優先事項であるべきです。

製造業では、組立ラインのダウンタイムを防ぎ、最小限に抑える方法について広範なプロセスと手順が存在します。1 また、ITサービス障害についても同様のプロセスが存在します。しかし、これらのほとんどは顧客に提供されるサービスの障害に焦点を当てており、サービスを構築・サポートする責任者のものではないことがわかりました。

「顧客が何かを望む」から「その何かが顧客に届けられる」までのすべてのコンポーネントについて考えることをお勧めします：

• GitHub IssuesやJiraなどの課題報告および変更要求システム
• IDEs、ビルドツール（Gradle、Mavenなど）、パッケージリポジトリ（npm、Maven Central、内部リポジトリなど）、ローカルデータベース、コンテナなど、開発者が直接ソフトウェアを構築するために使用するツール
• CI/CDツール（Jenkins、GitHub Actionsなど）。
• 失敗しているテストスイート（テストが失敗している場合、本番にデプロイしないはずですよね？）
• QAサーバーの障害（QAがテストしていない場合、本番にデプロイしないはずですよね？）
• 変更を行い、本番にデプロイすることを妨げる、文字通りプロセス内のあらゆるステップ

開発パイプラインが壊れたチームはソフトウェアを生産できず、これを本番障害として扱わなければなりません。

1 興味深いことに、彼らはしばしばそれを「生産ライン」と呼びます。ソフトウェア界での「production」という用語の使用は、製造業での歴史に関連しているのでしょうか？ ↩