DevOps における CI/CD とは？
継続的インテグレーション、デリバリー、およびデプロイ（以下「CI/CD」）は DevOps の手法です。 または、DevOps の理想を実装するテクニックと言い換えることができます。 この用語に聞きなれない方であれば、DevOps とは一体何であるのか、 また、それがアジャイルソフトウェア開発とどのように関連しているのかが気になるところでしょう。 ソフトウェア開発手法がどのように進化し、アジャイルと DevOps が解決しようとしている問題をより範囲を広げたコンテキストで理解すれば、CI/CD プロセスをさらに活用できるようになります。
アジャイルによる革命
デジタル革命のお陰で、ソフトウェアと IT は、多数の組織（ソフトウェアメーカーは別として）の単なる支援機能から、多くのビジネス業界の基幹部分への移行を果たしました。
銀行・金融業界から小売産業、行政から旅行やエンターテイメント業界に至るまで、ソフトウェア開発はあらゆる業界にわたって多くの組織の業務の中核的存在になってきています。 製品とサービスはアプリやオンラインサービスを通じてアクセスされており、アプリやオンラインサービスによって支えられています。社内コンピューターシステムにおいては、業務を円滑に遂行するための必需品となっています。
2001 年にこのトレンドが軌道に乗り出したころ、ソフトウェア開発者のグループはこのアジャイルマニフェストを作成しました。 これは、当時、ソフトウェアが開発されていた方法に存在していた問題の一部への答えとして出されたものでした。 マニフェストには、ソフトウェア開発の一連の価値と原理が記されており、それらを実践に取り入れたさまざまなフレームワークを生み出してきました。よく知られているものの 1 つに Scrum が挙げられます。
アジャイルでは、機能するソフトウェアを提供することに焦点が当てられるべきであり、人々が効果的にコミュニケーションとコラボレーションを行えることがその目標を達成するための基盤となることを認識しています。 要件が固まってから数年たった後にソフトウェアが提供され、そのころにはユーザーのニーズとコンテキストが大幅に変化してしまっていた当時の非常に長い時間のかかるウォーターフォール式のプロジェクトに対応して生み出されたアジャイルアプローチでは、要件の変更に対応することができます。
アジャイルフレームワークと方法論では、機能するソフトウェアの小分けした塊を定期的に提供し、フィードバックを収集して、それを基に適合させるという、反復的な作業が中心となっています。 これは、設計、開発、テスト、およびリリースという特徴的な線形のフェーズで作業を進めるウォーターフォール式アプローチから大きく異なるものでした。
DevOpsの理解
開発チームはアジャイルの原理を採り入れることで、ソフトウェア開発へのアプローチを変えつつありましたが、プロセスのさらに下流にあるチームとのコラボレーションはほとんど存在しませんでした。
インフラストラクチャの管理とソフトウェアの本番へのデプロイを担当するオペレーションチームがまったくことなる手法で作業し、コードを記述している開発者と異なる言語で有効な対話を持っていたことは、珍しいことではありません。
開発者がチーム内でいくら効率的に作業していたにしても、ビルドがオペレーションに渡ってしまった途端、ステージングにデプロイするプロセスでボトルネックが発生してしまうことがほとんどでした。 依存関係の欠落、環境構成の問題、開発者のローカルマシンでは再現できないバグによって、チーム間での延々としたやり取りと、どちらのチームに問題修正の責任があるかに関する意見の相違が生み出されていました。
これにはウォーターフォール式のリリース戦略も伴っていたことがほとんどです。変更は開発ごとに増分して提供されていましたが、後続のステップではそれらの変更が少ない頻度でリリースされる大きなバッチにまとめられ続けていたため、ユーザーから迅速なフィードバックを受ける機会がありませんでした。
カルチャの変化
「開発」と「オペレーション」を組み合わせた「DevOps」という用語では、機能するソフトウェアを効率的に提供するために、両チームのアクティビティを統合する必要があることが強調されています。 そうは言っても、そのスコープはこれらの機能に制限されているわけではありません。ソフトウェアの開発とデリバリーに関わるすべての人が、機能するソフトウェアをユーザーに提供するという共通の目標の下に活動する必要があります。
DevOps では、共同責任、相互信頼、およびオープンなコミュニケーションのカルチャを作ることが基本となっています。 ローカルビルドで機能した時点で、開発チームがタスクリストから作業項目を削除しているだけでは十分ではありません。 公開準備の整ったコードを提供するには、その作業からリリースまでのステップが開発者に確認できる状態である必要があります。 つまり、サイロを取り崩して、品質管理、セキュリティ、およびインフラストラクチャチームと協力し、プロセス内の担当部分を理解できるようにする必要があります。
DevOps ツールと自動化
チーム間で緊密な協力関係を結ぶことによって手作業のプロセスを達成することはできますが、ツールを使ってできる限り多くの作業を自動化すれば、さらに効率化することができます。 ビルド、テスト、およびデプロイステップを自動化すると、作業をより素早く完了させることができるため、それらのステージの結果をより早い時期に利用できるようになります。 品質を高めながら無駄を排除する上で不可欠となる短いフィードバックループを可能にする自動化は、DevOps の基本と言えます。
効率のよいプロセス
DevOps は、リーン生産の原理がソフトウェア開発に適用され始めたことに生まれました。 リーン方式では、品質を高め、労働者を尊重しながら、プロセスの各ステージを最適化することで無駄を除くことに焦点が当てられています。
DevOps はこの考え方の大部分を取り込み、エンドツーエンドプロセスを最適化して、ビルドされているものに対するフィードバックを短いフィードバックループでできるだけ早期に提供することで、ソフトウェア開発をさらに効率化することを求めています。
これには、開発の下流にあったアクティビティをより早い段階で実施するようにし、テストの失敗、セキュリティ脆弱性、またはビルド関連の課題など、それによって見つかった課題を見つかった時点で解決することが必要となります。
全員がソフトウェアをユーザーに提供するという責任を分かち合っているため、時間を無駄にする「自分のマシンでは動作する」といった回答では不十分です。 DevOps のアプローチでは、開発者は、ソフトウェアがどのように使用されており、どのような課題が発生しているのかということを非常によく確認することができるため、そういった課題を効率よく修正することができます。
DevOps を導入すると、開発チーム以外にもアジャイルのメリットがもたらされるようになります。 開発者から流れてくる作業のペースに合わせてより小さな塊で作業すれば、より少ない可変項目に取り組めばよいため、問題を見つけ、切り分けやすくなります。 同様に、フィードバックを迅速に生成することで、後で破棄されるビルドのテストやステージングに労力を無駄にする必要もなくなります。 組織全体が、より小さな増分に取り組むメリットを得ることができるのです。
DevOps を実践する
自動 CI/CD パイプラインを構築して、DevOps の理想を実現しましょう。
頻繁にコミットするという継続的インテグレーション手法では、パイプラインを迅速に移動できるバッチサイズを小さく維持することが勧められています。 自動ビルドとテストシステムを使えば、手作業によるプロセスよりも素早くそれぞれの変更を確認してフィードバックを提供することが可能になります。
開発者にとって、作成したばかりのものに迅速なフィードバックを得られれば、その内容のコンテキストが失われる可能性が減るため効率性が増します。リーン方式で言う「フロー」を維持することができるのです。 頻繁に行われる自動テストも、早めにバグをキャッチして修正することで、ほかのコードをバグのあるコードを基盤に構築せずに済むため、品質の改善に役立ちます。
本番前サーバーへのデプロイを自動化すると、プロセスに一貫性と確実性を持たせられるため、テストやフィードバック用にステージング環境をさらに活用する機会が提供されます。 小さな変更を大きなリリースにまとめて公開するのではなく、定期的に本番にデプロイすると、意図しない結果を生み出してしまう変数が少なくなるため、ライブ環境で問題が発生するリスクが軽減されます。
バグが実際に発生した場合でも、バッチサイズが小さいため、より素早く切り分けて修正することができます。 更新を少しずつリリースするということは、ユーザーに定期的に価値を提供するということであり、そういった変更へのフィードバックを使用して次の変更をビルドを決定することができ、製品をさらに改善していくことが可能となります。
まとめ
CI/CD、より一般的には DevOps は、品質を損なうことなく、価値のあるソフトウェアをユーザーに提供するプロセスを加速化することを目的としています。 DevOps の原理はアジャイルとリーンの考え方と重なり、それらを補完しています。 ソフトウェア開発の流れ全体を見つめ、各ステージを最適化すれば、より素早いデリバリーを可能にし、より素早くフィードバックを得て、継続的な開発と改善のサイクルを実現することができます。