本番リリースに実際に関わるのは誰か
開発者が新機能を書き終えた。コードはコンパイルされる。ローカルでテストは通る。プルリクエストは承認された。そして、本当の作業が始まる。
その機能がアプリケーションの他の部分と一緒に動作することを確認する人が必要だ。データベーススキーマの変更が既存のクエリを壊さないか確認する人も必要だ。この機能を今週リリースしても安全か、それとも待つべきかを判断する人も必要だ。サーバーに十分なキャパシティがあることを確認する人も必要だ。マーケティング、サポート、エンジニアリングが何が来るかを把握できるよう、タイミングを調整する人も必要だ。
もしスムーズに進んだリリースに参加したことがあるなら、それが単に開発者が良いコードを書いたからではないことを知っているはずだ。それは、それぞれが独自の焦点を持つグループの人々が、一つの目標、つまり何も壊さずにユーザーに機能を届けること、に向けて作業を調整できたからだ。
問題は、ほとんどのチームが何かがうまくいかなくなるまで、これらの役割について考えないことだ。セキュリティレビューはコードがすでにステージングされた後に行われる。DBAはデプロイが半分終わった時点でマイグレーションのことを知る。プロダクトマネージャーはエンジニアリングからではなく、サポートチケットから遅延の知らせを聞く。
コードが本番環境に向かうときに実際に誰が登場するのか、各人が何を気にしているのか、そしてなぜ彼らの関与がほとんどのチームが想定するよりも早い段階で重要なのかを見てみよう。
以下の図は、各ロールを中心的な関心事にマッピングし、リリースライフサイクル中にどのように接続するかを示しています。
開発者：コードを書くことは始まりに過ぎない
開発者は機能を書き、バグを修正し、プルリクエストを開く。その部分は目に見える。あまり目に見えないのは、その後のすべて、つまりコードレビューのフィードバックに対応し、CIで失敗するテストを修正し、ステージング環境がローカルと異なる動作をする場合に実装を調整し、デプロイ後何かが壊れた場合に備えて待機することだ。
開発者の自然な関心はスピードだ。彼らは自分のコードが迅速にユーザーに届き、フィードバックを得て、次のタスクに移りたいと考えている。それは怠惰ではない。集中力だ。しかし、その集中力は、他の役割が独自のチェックを行うために時間を必要とするときに緊張を生む可能性がある。
QA：ユーザーが気づく前に問題を見つける
QAの仕事は、自動テストが見逃すものをキャッチすることだ。すべてのバグにテストケースがあるわけではない。すべてのエッジケースがカバーされているわけではない。QAは探索的テストを実行し、受け入れ基準に含まれていなかったフローをチェックし、その機能が実際に解決すべき問題を解決していることを検証する。
ここでの緊張はタイミングだ。QAはテストするのに十分安定した機能を必要とするが、徹底的にテストするのに十分な時間も必要だ。期限が迫っていると、QAは圧迫される。そのときにバグがすり抜ける。
DevOps：コミットから本番への道筋を構築する
DevOpsは、コードを実行中のアプリケーションに変えるパイプラインを構築し、維持する。ビルドプロセスをセットアップし、デプロイスクリプトを管理し、環境設定を処理し、何かが失敗したときにパイプラインが明確なフィードバックを提供するようにする。
DevOpsはまた、厄介な部分、つまりシークレット管理、サービス間のネットワークアクセス、ビルドアーティファクトのストレージ、そしてデプロイが実際に成功したかどうかを教えてくれるモニタリングも扱う。パイプラインが遅かったり信頼性が低かったりすると、他のすべての役割がその影響を感じる。
SRE：デプロイ後もアプリケーションの安定性を維持する
SREはコードが実行された後に何が起こるかに焦点を当てる。エラーレート、応答時間、リソース使用量、そしてアプリケーションが健全であるか劣化しているかを示すあらゆるメトリクスを監視する。デプロイがエラーの急増を引き起こした場合、SREが最初に気づき、ロールバックするかどうかを最初に決定する。
SREの関心は安定性だ。彼らは変更が小さく、元に戻せ、本番環境に届く前に十分に理解されていることを望む。これは、迅速に出荷したいという開発者の欲求と時に対立するが、双方が互いの制約を理解していれば、その緊張は生産的だ。
DBA：データ層を保護する
データベースの変更は、どのデプロイにおいても最もリスクの高い部分だ。悪いマイグレーションはデータを破損し、テーブルをロックし、アプリケーションを数分または数時間ダウンさせる可能性がある。DBAはすべてのスキーマ変更をレビューし、パフォーマンスへの影響をチェックし、移行中に読み取りや書き込みをブロックしないマイグレーション戦略を計画する。
DBAの関与はしばしば遅すぎる。マイグレーションスクリプトは書かれ、コードは新しいスキーマに依存しており、DBAはデプロイの数時間前に承認を求められる。それは性急な決定とリスクの見落としのレシピだ。
セキュリティエンジニア：ドアが開かれる前に閉める
セキュリティレビューは、チームがプレッシャーにさらされているときにスキップされがちだ。しかし、リリース後に発見された脆弱性は、リリース前に発見されたものよりもはるかにコストがかかる。セキュリティエンジニアは、一般的な欠陥についてコードをレビューし、既知の脆弱性について依存関係をチェックし、認証と認可が正しく機能することを検証する。
課題は、セキュリティレビューが時間を追加することだ。セキュリティエンジニアが機能の完成後に関与した場合、どんな発見もやり直しを意味する。もし彼らが早期に関与すれば、最初から実装をより安全なパターンに導くことができる。
プロダクトマネージャー：何をいつリリースするかを決める
プロダクトマネージャーは、どの機能をリリースに含め、そのリリースをいつ行うかを決定する。ユーザーニーズ、ビジネスの優先順位、エンジニアリングのキャパシティのバランスを取る。また、リリース計画をステークホルダー、サポートチーム、マーケティングに伝える。
プロダクトマネージャーの悩みは可視性だ。彼らは機能が実際にいつ準備できるかを知る必要があり、コードが書かれたときではない。遅延がリリースを1日押し上げるのか、1週間押し上げるのかを知る必要がある。エンジニアリングからの明確なシグナルがなければ、彼らは推測に基づいて決定を下す。
リリースマネージャー：プロセス全体を調整する
大規模なチームでは、リリースマネージャーがリリースに入るすべての変更を追跡し、サービス間のデプロイのタイミングを調整し、承認プロセスを管理し、ロールバック計画が存在することを確認する。複数のチームが一緒にデプロイする必要がある場合、彼らは調整の単一窓口となる。
リリースマネージャーの仕事は驚きを防ぐことだ。彼らは他の誰も尋ねていない質問をする：誰がこれを承認する必要があるのか？マイグレーションが失敗したらどうなるのか？監視チームはデプロイを認識しているか？これらの質問が行われないと、リリースは混沌とする。
次回のリリースのための実用的なチェックリスト
すべてのチームにこれらの役割を専任で担当する人がいるわけではない。小規模なチームでは、一人が複数の役割を担う。誰がその作業を行うかに関係なく、チェックリストは依然として適用される。
- コードを書く前に、この変更に関与する必要がある役割を特定する
- セキュリティとDBAは、コードがデプロイ可能になったときではなく、早い段階で関与させる
- QAには、まだ変更中のコードではなく、テストするのに十分な時間と安定したコードを提供する
- パイプラインが単なる緑や赤ではなく、明確な失敗シグナルを提供することを確認する
- ロールバック手順が文書化されているだけでなく、テストされていることを確認する
- リリース計画をエンジニアリングだけでなく、知る必要があるすべての人に伝える
まとめ
成功するリリースは、一人の優れたコードを書いた結果ではない。それは、それぞれ異なる優先順位を持つ複数の人々が、共通の成果に向けて作業を調整した結果だ。迅速に出荷する開発者、エッジケースをキャッチするQA、データを保護するDBA、脆弱性を塞ぐセキュリティエンジニア、優先順位を設定するプロダクトマネージャー、そして全体を調整するリリースマネージャー。彼ら全員が重要だ。
次に本番環境に出荷するときは、自問してみてほしい：誰が関与する必要があり、彼らは適切なタイミングで関与しているか？その答えは、どんなパイプラインダッシュボードよりも、あなたのデリバリープロセスについて多くを教えてくれるだろう。