DevOpsのテキスト研修
品質を確保するためになぜ継続的なレビューが必要か
組織では、本番デプロイ直前のレビュー、監査、検査、承認に大きく依存していることがあります。検査するのは、作業とほとんど関わりがないか、まったく関わりのない人であることが一般的です。さらに、検査や承認の権限者が作業を誤解している場合もあり、コードを本番環境にデプロイしようとする直前に、説明して理解してもらわなければなりません。
外部の統制の仕組みの問題
多くの組織では、相互の信頼を築くよりも、統制の仕組みを増やすほうが簡単です。そのため、変更管理の書式に質問を追加し、承認の階層を増やし、変更を理解して承認するのにさらに時間がかかるといった問題がよく起きます。
指示と統制を重視し、信頼の低い組織文化では、同じインシデントが繰り返し起こります。実際の作業や再発する問題が見えず、負担の大きいデプロイの回数を減らすために、大きな単位でまとめて作業するので、悪循環が生まれます。デリバリーまでの時間が延びると、市場投入の速さで競争力を失います。フィードバックが遅く、手遅れになってから届き、具体的な行動にもつながらなければ、チームはミスから学べません。
優れたDevOps組織は、実際の作業やその問題を最もよく知るのは、現場に最も近い人だと理解しています。外部の統制や承認を増やしても、バリューストリームに価値は加わりません。ここに現代のマネジメントとリーダーシップの最大の課題があります。実際の作業が透明で、心からの尊重と相互の信頼が日常業務の土台になる文化を築くことです。
定期的な検査への依存を減らし、日々の仕事にピアレビューを取り入れます。安全にデプロイできるよう、DevOpsチームの開発者、運用エンジニア、品質保証と情報セキュリティの専門家が常に協力し、互いの作業を確認します。
外部の統制に頼らず複雑な作業を調整する
一つのチームで一つのプロジェクトに取り組むだけでも複雑ですが、複数のチームが同じシステムの異なるコンポーネントを担当すると、さらに複雑になります。あなたとDevOpsチームが状況を把握し続けるための対策を挙げます。
- 管理者だけでなく各分野の専門家で構成される変更審査委員会は、変更前に各チーム間の依存関係を把握するのに役立ちます。
- SOAとマイクロサービスに基づく疎結合なアーキテクチャは、依存関係とコミュニケーションの手間を減らす。
- DevOpsチームの技術担当者は、依存関係と開発・デプロイの順序を特定します。
- 共通のチャットプラットフォームで継続的に連絡を取り、変更の足並みをそろえ、互いにどこまで理解しているかを確認します。
- 移行やインフラ変更など、影響が大きくリスクの高い変更には、テスト環境でのリハーサルと、フェイルオーバーや完全なロールバックの仕組みなどの技術的な対策が必要です。
高い成果を上げるDevOps組織はピアレビューを重視し、外部承認への依存を減らす
Amazon、Netflix、Etsy、GitHubを含む多くの有力なDevOps組織は、「プルリクエスト」によるレビューとデプロイのプロセスを使っています。流れは次のとおりです。
- 開発者はトランクから別の開発ブランチを作ります。ブランチを存続させるのは数営業日以内にし、「login-screen-v2」のように、内容が明確に伝わる名前を付けます。開発者は自分のワークステーション上でローカルに作業し、そのブランチを定期的にバージョン管理システムへチェックインします。
- 開発ブランチをトランクにマージできると判断したら、プルリクエストを開き、レビューとフィードバックを求めます。
- 他のDevOpsチームメンバーからフィードバックと承認を得た後で、開発者はコードをトランクにマージします。その後、本番システムにコードをデプロイします。
データベーススキーマや、アプリケーションの情報セキュリティに影響し得る変更など、特に重要な変更については、追加のプルリクエストを送り、データベース管理者や情報セキュリティ担当者など、組織内の他の専門家からフィードバックを得ることもできます。
コードレビューでも、バッチサイズを小さくする原則を適用します。そうしなければレビューが長引き、担当エンジニアの負担が増します。変更が大きくなるとリスクは指数関数的に増え、レビューの信頼性が下がります。変更が大きすぎて理解しにくいときは、開発者に、小さく理解しやすい複数の単位に分けるよう求められます。
職位や経験に関係なく、DevOpsチーム全員が、自分の変更を誰かにレビューしてもらう必要があります。全員でコミットの流れを見ておけば、パイプラインや、さらに重大な本番デプロイの問題に発展する前に、競合の可能性をすばやく見つけ、解決できます。
ペアプログラミング単独でも、テスト駆動開発（TDD）と組み合わせても、コードを書きながらピアレビューできます。組み合わせる場合、一人がアプリケーションのコードを書き、もう一人が自動テストを書きます。チームの規模と要件が同じ条件では、ペアプログラミングは時間が15%多くかかる一方、コーディングのエラーを85%減らすことが測定によって実証されています。DevOpsチームでの活用を検討すべき重要な実践です。
ほかにも、担当者の横で一緒にコードを見るレビュー、チェックインの自動通知、コードレビューと品質向上を支援するツールの導入を検討できます。
まとめ
組織内の各DevOpsチームが、自分たちの成果物の品質に責任を持つようにします。質の高いコードを書くことと同じくらい、継続的で質の高いコードレビューを大切にする文化を築きましょう。
