DevOpsのテキスト研修

DevOpsの継続的デリバリーとデプロイメントパイプラインをどう設計するか

多くの組織では、おそらくあなたの組織でも、開発者が別々のコードブランチに分かれて作業しています。一人ひとりの生産性は高まるように見えても、チーム全体の生産性は下がります。

コードブランチを分けると、複数の開発者のコードをマージしにくくなります。異なるコード片を統合し、連携して動作させ、顧客に機能と価値を届けるには、通常、複数の開発者の協力、大幅な手戻り、以前に解決しておくべきだった競合への対処が必要です。

継続的に統合しないと課題が大きくなる

皮肉なことに、コードのマージはビルドサイクルの中で難しく疲れる作業なので、多くの開発チームは、アプリケーションを統合テストやユーザー受け入れテストに引き渡す直前になってコードをマージし、問題をさらに深刻にします。共同で書いたコードの統合と品質を品質保証チームだけの責任にします。これは理にかなわないだけでなく、プロジェクトが遅れ、予算超過が急増し、チームの士気と意欲が落ち、組織の目標や約束が果たせず、世界の企業が予算外、計画外のIT業務に年間約6,000億米ドルを浪費する理由をよく示しています。言い換えれば、ITの手戻りや回避策にかかる費用です。

トランク（メインのコードブランチ）を軸にした開発はどう役立つか

この課題の解決策は、トランクベース開発と継続的インテグレーション、テスト自動化を組み合わせることです。トランクベース開発は、開発者が「トランク」と呼ばれる単一のブランチ上でコードを共同開発する、ソース管理のブランチモデルです。長く存続する別の開発ブランチを作る圧力に屈しません。

トランクベース開発は、継続的インテグレーション、ひいては継続的デリバリーを実現する鍵です。開発者が1日に何度も変更をトランクにコミットすれば、チーム全員が少なくとも24時間に1回コミットするという継続的インテグレーションの中核要件を満たしやすくなります。コードベースはいつでも必要に応じてリリースできる状態になり、継続的デリバリーの実現につながります。

継続的インテグレーションで、小さくデプロイ可能な単位でコードを届ける

開発者が頻繁にチェックインすれば、開発とデリバリーの単位が小さくなり、品質が高まり、問題や競合を解決しやすくなります。毎日のチェックインによる継続的インテグレーションは、CIと継続的デリバリーの仕組みの整合性を保ちながら、デプロイ可能で意味のあるコードを小さな単位で作るよう促します。共通のソースコードリポジトリの更新は、チームがすばやく認識を合わせ、判断し、フィードバックを交わす手段にもなります。

コードがチェックインされるたびに、継続的インテグレーションの仕組みは、変更したモジュールに依存する機能や、影響を受ける機能の自動テストケースを実行します。何かが壊れた場合は、そのチェックインを行った人が最優先で修正します。他のメンバーがトランクへの統合を続けられるようにするには、その時点で最も重要な作業です。トランクの安定性と信頼性を守るため、問題のあるチェックインをすばやく修正するかロールバックするまでは、そのモジュールへの他のチェックインを認めません。

この重要なDevOps原則とは違う考え方をするなら、答えるべき問いがあります。すでにエラーのあるモジュールに、なぜ新しいコードを追加するのでしょうか。

正当な理由があるかもしれませんが、技術的負債や、回避策の上に回避策を重ねる事態は避けましょう。

ゲート付きコミットでトランクベース開発の安全網を強化する

DevOpsチームはゲート付きコミットも利用できます。品質をさらに高め、トランクにもう一つ安全網を設けられます。

開発者がコードをチェックインしようとするたびに、まず自動テストを実行してコードを検証します。検証に成功した場合にのみ、正式にトランクにチェックインされます。

ソフトウェアエンジニアリングのバリューストリーム全体で本番に近い環境を使う

多くのIT組織に共通する別の課題は、本番環境と本番前の開発、統合、テスト環境の不整合です。オペレーティングシステム、データベース、サードパーティのツールやAPIの設定、バージョン、パッチレベルが異なる場合があります。自社コードの異なるバージョンが複数の本番環境や本番前環境に散在していることもあります。本番前環境と本番環境でJVMのバージョンがわずかに違うだけで、本番デプロイ全体の成否が左右されます。環境を完全に制御し、何が入っているかを把握しなければ、どんな結果になるか予測できません。

環境管理を日々のソフトウェア開発とデリバリーに組み込む

本番前環境を本番環境の複製にすることは、自然な判断です。チームが本番に近い環境で日々のエンジニアリング作業を安全に進められるよう、必要なときにセルフサービスで環境を自動作成できるようにします。

組織のITバリューストリームが提供する価値は、ソフトウェアのコードと、そのコードが動く環境の両方から生まれます。開発と運用の専門家は、バリューストリームが同じくらい重要な二つの要素からなることを認識する必要があります。

1. 社内顧客、社外顧客、またはその両方に価値を提供するソフトウェアをビルドするコード。
2. ソフトウェアを稼働させる本番前環境と本番環境を構築するコード。

唯一の信頼できる情報源（トランク）でソフトウェアと環境を管理する
（インフラストラクチャのコード化、IaCを取り入れる）

DevOpsでは、本番前環境と本番環境を構築する作業がトランクの一部になります。これがインフラストラクチャのコード化（IaC）の最も純粋な定義です。環境で動かすソフトウェアの詳細をほとんど知らない運用チームが単独で担当するのではなく、開発と運用の専門家が協力して、インフラストラクチャをコードで構築します。

ソフトウェアのコードと環境のコードを同じように扱うため、両方を単一の信頼できる情報源であるトランクに保存します。

本番前と本番の全システム、および継続的インテグレーションとデリバリーの仕組みを含むデプロイメントパイプラインを構築できるよう、ソフトウェアのコードに加えて、必要な設定、スクリプト、デリバリーの全工程を構築するために必要なものをバージョン管理システムに保存します。環境設定を永続的に変える場合は、環境構築用のスクリプトを変更します。次にチームメンバーが環境を作るときに、同じ手順を一から考え直さずに済みます。

詳しい文書の多くはすぐに古くなるので、環境構築用のスクリプトを最新に保つほうが、労力の有効な使い方です。必要に応じてセルフサービスで環境を用意できなければ、クラウド基盤は十分に活用されないホスティング環境に、DevOpsも十分に活用されない改善の試みにとどまります。本番と本番前の環境全体をバージョン管理システムから作れるようにします。DevOpsでは、環境を修理するより再構築するほうが簡単で速くなります。環境を手作業で変更せず、コードと設定だけで再構築、設定、起動します。

完了の定義（DoD）を見直す

継続的デリバリーの仕組みとデプロイメントパイプラインが動き始めたら、新たな「完了の定義（DoD）」が必要です。

タスクは、関連する顧客向けの機能や便益が次の条件を満たしたときに「完了」とします。

• トランクから自動またはワンクリックで作成できている。
• 本番に近い環境で自動テストを実行済みである。
• 本番に近い環境でデモを行っている。
• デプロイ可能であるか、できれば自動またはワンクリックで、稼働中の本番環境にすでにデプロイされている。

まとめ

DevOpsでは、プロジェクトの終盤を待たず、日々の業務の一部としてコードを統合します。開発者、運用チーム、情報セキュリティの専門家が、ソフトウェアエンジニアリングのライフサイクルの途中からデプロイを繰り返し練習します。実際の本番デプロイが円滑に進む可能性は確実に高まります。

継続的インテグレーションを取り入れると、事業の処理能力、ソフトウェアと環境の安定性、仕事の満足度、社内外の顧客に提供するサービスの品質も向上します。