アジャイル継続的インテグレーション
DevOps が登場する前、つまり継続的インテグレーション、デリバリー、およびデプロイ（CI/CD）が生まれる前は、アジャイルにこれらのアプローチと密接な結びつきがありました。 アジャイルの考え方を理解すれば、アジャイルを実践に持ち込む CI/CD パイプラインを実装する際に、CI/CD を最大限に活用しやすくなります。
残念ながら、長年のフレームワーク、戦略、およびコンサルティングにより、アジャイルの核となる信条は曖昧になり、厳格なルールのセットへと縮小されてしまいました。 しかし、その原理を理解しなければ、有効に適用するのがさらに困難になります。
アジャイルの原理
アジャイルは何よりもまず観点であり、ソフトウェアを開発する際のプロセスに対する考え方を指します。
アジャイルは、機能するソフトウェアを提供するという目標と、変更を受け入れて各関係者のコラボレーションを促進することが、契約要件の計画に厳格に従うよりも効果的に達成できることを認識しています。
アジャイルマニフェストに定義される原理は、これらの価値に基づいて展開し、それを実践に移すためのテクニックを提供しています。 これらには、権限を与えられた協力関係をもつチームを構築することと、機能するソフトウェアを頻度の多い反復的サイクルで提供することが含まれており、こうすることでチームが変更に対応できるようになります。
理由は単純で、最初に要件を明確に設定し、それらを提供する計画に厳密に従うと、さらに知識や情報が増えて、ユーザーのコンテキストとニーズが進化するにつれて、構築しているものを適応させる柔軟性が失われてしまうためです。 アジャイルアプローチは、最終目標を設定し、それを達成するための具体的な方法を段階的に解決する手法を指します。
CI/CD でアジャイルを実現する
こういったアジャイルの原理によって DevOps へのムーブメントが起こり、CI/CD の手法が誕生しました。
少なくとも当初のアジャイルの焦点は、開発チームの働きに関していましたが、DevOps はそれを下流のプロセスと、作成されているコードをリリースに持ち込む上で伴う作業にまで拡張させています。
DevOps はサイロを取り崩し、チーム間で協力し合って、機能する有用なソフトウェアをユーザーに届けるという共通の目標を達成する重要性を強調しています。 継続的インテグレーション、デリバリー、およびデプロイは、品質を損なうことなくソフトウェアの提供を加速化させることを目標とした DevOps 手法です。
プロセス内のステップをできるだけ多く自動化することで、継続的インテグレーション環境の迅速なフィードバックにより、ソフトウェアがユーザーにリリースされるまでの期間を短縮することができます。
アジャイルと DevOps の過去に基づけば、ビルドパイプラインに関わっている複数の要素もアジャイル方式で作業する際に役立つことに気づくことでしょう。 手始めに、「早期かつ頻繁にコミット」という CI の推奨される実践では、小さなバッチで作業するように勧められています。
反復的なビルドとリリースのプロセスでは、機能をより小さなピースに分解することが不可欠です。 すべてのコミットが CI/CD ワークフローを進んでリリースされるようにすることが目標であるため、各コミットが機能するものになるようにする必要があります。 したがって、このアプローチを採用することで、機能するソフトウェアの提供に集中し続けることができます。
アジャイルと DevOps は共に、コラボレーションとコミュニケーションの価値を強調しています。 DevOps の最初の焦点は開発と運用の間のコラボレーションですが、そのメリットはさらに広範に展開されます。
ステージング環境をビルドパイプラインに含め、ダッシュボードで各ビルドの変更点をわかりやすく表示することで、マーケティング、デザイン、またはセキュリティチームといった組織の別の部門と進捗状況を共有し、フィードバックを提供するように依頼することができます。
CI/CD パイプラインの中枢には、コードの変更に対するフィードバックを迅速に提供し、ビルドの品質に自信を与える自動テストがあります。 コミットごとに自動テストを実行することは、機能するソフトウェアの提供を保証する上で重要なステップです。
アジャイル計画では、ソフトウェアをユーザーに頻繁にリリースすることが最優先であり、CI/CD パイプラインはその原理を実現することのできる鍵と言えます。 リリースプロセスのステップを自動化することによって、チームはリリースを大幅に加速し、毎日、さらには 1 時間ごとに、変更をデプロイすることが可能になっています。これは、マニフェストが作成された当初に描いていた頻度より、かなり高い結果です。
最後に、CI/CD の中核を成し、構築中のソフトウェアとそれを実現するプロセスの両方の継続的な改善を可能にする継続的なフィードバックサイクルによっても、チームが定期的にプロセスを省みて適宜調整するというアジャイルの原理が強化されています。 フィードバックループを組み込んでそれに耳を傾けることで、マニフェストに記された持続可能な開発ペースを確立することが可能になります。
アジャイルな組織の構築
CI/CD パイプラインの実装によってアジャイルな考え方が育まれる可能性はありますが、それはアジャイルが最初に定義されて以来急増しているさまざまなアジャイルフレームワークとソリューションにすぎません。
とはいえ、CI/CD の手法に共通するいくつかのアンチパターンは、期待したほど組織がアジャイルではないことを示す指標にもなります。
継続的インテグレーション環境における有効なビルドパイプラインの運用とアジャイル原理の採用によく見られるハードルは、リリースプロセスにさまざまな手動のステージを導入することです。 これには、新しいビルドが本番にデプロイされる前の諮問委員会の変更や詳細な変更通知とリスク評価の要件などがあります。
こういった手続きは通常、リリースをある程度監視して制御できることを保証することを意図していますが、 これでは、プロセスを大幅に遅らせ、ビルドへの自信を与えるべき自動テスト体制の目的が失われてしまいます。
こういった懸念は、メトリクスを用いて CI/CD パイプラインの堅牢性を示すことで軽減しやすくなります。 同時に、ダッシュボードと自動通知によって、パイプラインを介して行われる変更を関係者に通知し続けるための多くの手作業を削減することができます。
もう 1 つの一般的な警告サインは、プロセスの速度を低下させ、変更をより頻度の低いリリースにバッチ化する要求の出現です。
一部の製品では、変更をウィークリーまたはフォートナイトリーの更新にまとめる方が適切である場合もありますが、それよりも頻度が低くなると、変更を本番に公開し、それから得たフィードバックを次のステップで使用するというメリットが損なわれてしまうリスクがあります。
アジャイル継続的インテグレーション、DevOps、および CI/CD 手法の背後にある理論的根拠を伝え、組織の全レベルからこのプロセスへの賛同を得ることで、円滑な移行を実現しやすくなります。
信頼に欠けていれば、必要なことを実現するための権利がチームに与えられないため、それが CI/CD とアジャイルを根底的に阻止してしまいます。 決定や変更において複数のレベルの承認が必要であれば、プロセスの速度が低下するだけでなく、迅速なフィードバックのメリットが損なわれてしまいます。
権限を与えられたチームは、チームメンバーが作業を実行できるようにするための適切なツールと環境をチームに提供するために、実用的なソフトウェアと管理を提供する必要があります。
まとめ
アジャイルは、特定の方法で適用される必要のある固定されたルールセットととして誤って解釈されることがあります。 理論的根拠を理解し、アンチパターンに警戒しながらその原理を組織に採用することによって、アジャイル継続的インテグレーションの考え方を促進することができます。
CI/CD 手法を採用すると、アジャイルの価値を実践に採り入れ、反復的な開発サイクルと頻繁なリリースのメリットを実現することができます。