DevOps パイプライン

1. 継続的インテグレーション/継続的デリバリー/デプロイ (CI/CD)

継続的インテグレーション とは、共通のソース コード リポジトリに対して頻繁にコミットするプラクティスです。コードの変更を既存のコードベースに継続的に統合するために、異なる開発者のコード変更間の競合を迅速に特定して、比較的簡単に修正できます。このプラクティスは、デプロイの効率を高めるために非常に重要です。

トランクベース開発は継続的インテグレーションの要件と考えられます。共有ソース コード リポジトリの共通ブランチに頻繁にコミットしない場合は、継続的インテグレーションを行っているとは言えません。構築プロセスとテスト プロセスが自動化されていても、開発者が分離されたフィーチャー ブランチで長期的に作業していて共有ブランチにはほとんど統合されない場合も、継続的インテグレーションは行われていません。

継続的デリバリーは、アプリケーションのソース コードの "メイン" または "トランク" ブランチを、常にリリース可能な状態にしようとする試みです。言い換えれば、経営陣が金曜日の午後 4 時 30 分にデスクに来て「最新バージョンを今すぐリリースする必要がある」と宣言しても、ボタンを押すだけで、障害を恐れることなくそのバージョンをデプロイできます。

このためには、本番環境にできるだけ近い本番前環境を用意し、自動テストが実行されるようにして、コードがメイン ブランチまたはトランク ブランチにマージされる前に、障害を引き起こす可能性のあるすべての不確定要素を特定しておきます。

継続的デプロイは、継続的なテストと運用のレベルを非常に堅牢にして、人間の手を借りずに新しいバージョンのソフトウェアを検証して本番環境にデプロイするというものです。

これを使用するのは稀で、ほとんどの場合は不要です。通常、このレベルの自動化を必要とする (または希望する) のは、数百人、数千人もの開発者を抱える、毎日多数のリリースがあるユニコーン企業だけです。

継続的デリバリーと継続的デプロイの違いを単純化して説明するなら、デリバリーは宅配業者が荷物を届けること、デプロイはその荷物を開封して中身を使うことだと考えてください。もし荷物を受け取ってから開封するまでの間に製品の変更が必要になれば、メーカーは厄介なことになります。

2. 継続的フィードバック

従来のウォーターフォール方式によるソフトウェア開発の最大の弱点であり、結果的にアジャイル手法が設計された理由にもなっているのは、タイムリーなフィードバックの欠如でした。新しい機能のアイデアから実装までに数か月または数年かかる場合、最終製品は顧客が期待していたものや望んでいたものとは別のものになることはほぼ間違いありません。アジャイルは、開発者が関係者からより迅速なフィードバックを受け取れるようにすることに成功しました。DevOps により、開発者は関係者からだけでなくパイプラインにおけるコードの体系的なテストと監視からも継続的なフィードバックを受け取れます。

継続的なテストは、すべての DevOps パイプラインの重要なコンポーネントであり、継続的なフィードバックを実現する主な要素でもあります。DevOps プロセスでは、変更が開発からテスト、デプロイへと継続的に移動するため、リリースの迅速化だけでなく製品の品質向上にもつながります。これは、すべてのビルド変更で実行されるユニット テスト、スモーク テスト、機能テスト、エンドツーエンド テストなど、パイプライン全体でテストを自動化することを意味します。

継続的なモニタリングは、継続的なフィードバックのもう 1 つの重要なコンポーネントです。DevOps のアプローチでは、ステージング、テスト、さらには開発環境における継続的なモニタリングの使用も伴います。本番前環境で異常な動作がないかを監視することが役立つ場合もありますが、一般的には、これは本番環境のアプリケーションの健全性とパフォーマンスを継続的に評価するために使用されるアプローチです。

この機能を提供するツールやサービスは数多く存在します。これは、サーバー リソースやネットワーキングなどのオンプレミスまたはクラウドのインフラストラクチャの監視から、アプリケーションや API インターフェイスのパフォーマンスの監視まで、多岐にわたります。

3. 継続的な運用

継続的な運用は比較的新しく、あまり一般的でない用語であるため定義もまちまちです。1 つの解釈としては "継続的なアップタイム" があります。たとえば、ブルー/グリーン デプロイ戦略の場合は、"ブルー" (パブリック アクセス可能) と "グリーン" (パブリック アクセス不可) の 2 つの本番環境があります。この状況では、新しいコードがグリーン環境にデプロイされ、それが機能することが確認されるとスイッチが (通常はロードバランサで) 切り替えられ、トラフィックが "ブルー" システムから "グリーン" システムに切り替わります。その結果、エンドユーザーのダウンタイムは発生しません。

継続的な運用のもう 1 つの考え方は、継続的なアラートです。これは、アプリケーションまたはインフラストラクチャでパフォーマンスの異常が発生した場合、エンジニアリング スタッフはオンコールで通知を受けるという概念です。ほとんどの場合、継続的なアラートは継続的な監視と連動します。