開発者がコードをプッシュすると実際に何が起きるのか
バグ報告が届く。ユーザーが確認画面でフリーズして支払いを完了できない。開発者がコードを開き、問題を見つけ、修正を書き、ローカルでテストする。自分のマシンではすべて正常に動く。修正を共有リポジトリにプッシュする。
そのプッシュは始まりに過ぎない。この後何が起きるかで、修正がユーザーに届くまでが数分なのか、数時間なのか、数日なのかが決まる。同時に、チームが経験するストレス、混乱、手戻りの量も決まる。
ここでは、開発者のラップトップから本番環境に至るまでの、たった一つの変更の全行程を追いかけよう。各ロールが実際に何をしているのか、そしてロール間の引き継ぎが、ほとんどのチームが思っている以上に重要な理由を見ていく。
開発者：ローカルから共有へ
開発者はまず、変更をバージョン管理にコミットする。コミットとは、Gitのような共有リポジトリに保存された変更のスナップショットだ。しかし、コミットしただけでは変更の準備は整ったとは言えない。開発者は次にプルリクエストまたはマージリクエストを開き、自分の変更をメインブランチにマージするよう依頼する。
この時点で、自動チェックが動き出す。コードがコンパイルまたはビルドされ、実行可能な状態になる。ユニットテストが個々の関数を検証し、結合テストがアプリケーションの異なる部分が連携して動作するかを確認する。基本的なセキュリティスキャンも実行されるかもしれない。これらはすべて、誰もキーボードに触れることなく行われる。
いずれかのテストが失敗すれば、開発者に通知が届く。開発者は問題を修正し、再度コミットし、このサイクルを繰り返す。すべてのテストが通れば、コードは次のステージに進む準備が整う。
ここで多くのチームが行き詰まる。パイプラインがグリーンでも、変更が安全だとは限らない。自動チェックが通ったというだけだ。誰かが人間の目で変更を見る必要がまだある。
次のシーケンス図は、開発者のプッシュから本番環境に至るまでのコード変更の全行程を、ロールとシステム間の主要なやり取りとともに示しています。
QA：自動化を超えたテスト
品質保証はビルドの準備ができてから始まるわけではない。QAエンジニアは通常、フィーチャーや修正がまだ計画されている段階でテストシナリオを準備する。エッジケース、異常な入力、低速なネットワーク状態、システムの他の部分との相互作用について考える。
ビルドが自動チェックを通過すると、QAがそれを受け取り、ステージング環境にデプロイする。ステージングは本番環境のコピーであり、実際のユーザーはアクセスしない。ここで手動テストが行われる。
QAは準備したシナリオを実行する。新しい機能は期待通りに動作するか？他の何かを壊していないか？ユーザーフローは自然に感じられるか？また、自動テストが見逃す可能性のある経路も探索する。テキストフィールドに非常に長い文字列を入力するとどうなるか？データベース接続が遅い場合はどうか？
QAが問題を見つけた場合、開発者に報告する。開発者が修正し、再度コミットし、QAが承認するまでこのサイクルを繰り返す。この行き来は正常なことだ。失敗の兆候ではない。自動テストでは予測できない問題をチームがキャッチする方法なのだ。
重要な点は、QAは最後にテストするだけではないということだ。彼らは何が構築されるかに最初から影響を与える。QAを最終ゲートとして扱うチームは、常に問題を発見するのが遅すぎる。
DevOps：変更を安全に本番環境へ
QAがビルドを承認すると、デプロイに移る。ここでDevOpsが主導権を握る。DevOpsエンジニアは、承認されたビルドを何も壊さずに本番環境に投入する責任を負う。
シンプルな設定では、デプロイは手動かもしれない。DevOpsエンジニアがサーバーにログインし、最新のビルドをプルし、古いバージョンを新しいものと入れ替えるコマンドを実行する。より成熟した設定では、デプロイは自動化されている。ボタン一つ、あるいはQA承認後の自動トリガーで、プロセス全体が処理される。
しかし、デプロイが終わりではない。新しいバージョンが稼働した後、DevOpsはシステムを監視する。エラー率は正常か？応答時間は許容範囲か？ユーザーは新機能にアクセスできるか？何かおかしければ、DevOpsは以前のバージョンにロールバックし、開発者とQAが調査できるようにする。
この監視フェーズはしばしば見落とされる。チームはデプロイの成功を祝って次に進み、何時間も経ってから、微妙なバグがユーザーに影響を与えていることに気づく。優れたDevOpsのプラクティスには、すべてのデプロイ後に少なくとも短い期間システムを監視することが含まれる。
引き継ぎはツールよりも重要
よくある誤解は、開発者、QA、DevOpsが厳格な組み立てラインで働くというものだ。開発者が終えたらQAに渡し、QAが終えたらDevOpsに渡す。実際には、彼らはプロセス全体を通じてコミュニケーションを取っている。
開発者がステージング環境の設定についてDevOpsに質問するかもしれない。QAが開発者に特定の自動テストを追加するよう依頼するかもしれない。DevOpsが、設定ミスのために前回のデプロイが予想より長くかかったことを開発者に伝えるかもしれない。これらの会話がスムーズであればあるほど、変更はより速くユーザーに届く。
CI/CDパイプライン、自動テストフレームワーク、デプロイ自動化といったツールは役立つ。しかし、それらはコミュニケーションを代替しない。基本的なツールでもうまく話し合うチームは、高度なツールを使ってもまったく話さないチームよりも優れた成果を出す。
他のロールが登場するとき
チームが成長し、デプロイ頻度が増えるにつれて、さらに二つのロールが登場することが多い。Site Reliability Engineer（SRE）とPlatform Engineerだ。
SREは信頼性に焦点を当てる。サービスレベル目標を設定し、システムの健全性を監視し、インシデントに対処するための自動化を構築する。チームが1日に複数回デプロイし、各デプロイがシステムを劣化させないことを保証する必要がある場合に、SREが通常必要になる。
Platform Engineerは、他のチームが使用する内部ツールとインフラストラクチャを構築する。開発者がDevOpsを待たずにデプロイできるセルフサービスプラットフォームを作成する。組織に複数のチームがあり、各チームが個別に管理するにはインフラが複雑になりすぎた場合に、Platform Engineerが必要になる。
これらのロールは、開発者、QA、DevOpsを置き換えるものではない。より高い速度と複雑さに対処するためのチームの能力を拡張する。
変更フローのための実践的チェックリスト
このチェックリストを使って、チームがコミットから本番環境までの変更をどのように処理しているかを評価しよう。
- すべてのコミットが自動ビルドとテストをトリガーするか？
- QAはビルドの準備ができる前にテストシナリオを準備しているか？
- 本番環境をミラーリングしたステージング環境があるか？
- DevOpsは数分以内にデプロイをロールバックできるか？
- デプロイ後、少なくとも30分間は誰かがシステムを監視しているか？
- 開発者、QA、DevOps間の明確なコミュニケーションチャネルがプロセス中に存在するか？
これらのいずれかが欠けている場合、そこが摩擦の発生源になる。
これがあなたのチームにとって意味すること
コードから本番環境への変更の移動は、人間による中断がある技術的プロセスではない。それは技術的ツールに支えられた人間のプロセスだ。ロール間のコミュニケーションの質が、変更がどれだけ速く、どれだけ安全にユーザーに届くかを決定する。自動化は役立つが、明確な引き継ぎ、共通の理解、適切なタイミングで適切な人を巻き込む姿勢を代替することはできない。
次にあなたのチームが変更をプッシュするときは、引き継ぎに注目しよう。そこで本当の仕事が行われているのだ。