KubernetesとJenkinsによるCI/CDパイプラインの構築 パート1

長い記事なので、3回に分けて投稿いたします。今回は1回目です。

CI/CDは、DevOps、Agile、Scrum and Kanban、Automationなどの他の用語と並んでよく耳にする言葉です。CI/CDは、DevOpsやAgile、Scrum、Kanban、自動化などの用語と一緒に耳にすることが多く、CI/CDとは何か、なぜCI/CDが採用されたのかをよく理解しないまま、単なるワークフローの一部と考えられていることがあります。CI/CDの存在を当たり前のものと考えているのは、ソフトウェアのリリースサイクルの「昔からある」方法を見たことがなく、それゆえにCI/CDを評価できない若いDevOpsエンジニアたちです。

CI/CDとは、継続的インテグレーション/継続的デリバリーもしくは 継続的開発の略です。CI/CDを導入していないチームは、新しいソフトウェア製品を作る際に、以下のような段階を経る必要があります。

1. プロダクトマネージャー（お客様のニーズを特定する）は、製品が持つべき必要な機能と、製品が従うべきビヘイビアを提供します。ドキュメントは可能な限り徹底して具体的でなければなりません。

2. 開発者はビジネスアナリストとともに、コードを書き、ユニットテストを実行し、その結果をバージョン管理システム（gitなど）にコミットすることで、アプリケーションの開発を開始します。

3. 開発フェーズが終了すると、プロジェクトはQAに移行します。ユーザー受け入れテスト、統合テスト、パフォーマンステストなど、製品に対していくつかのテストが行われます。QAフェーズが終了するまでは、コードベースに変更を加えてはいけません。万が一バグがあった場合は、開発者にフィードバックして修正してもらい、製品をQAに戻します。

4. QAが完了したら、オペレーションチームがコードを本番環境にデプロイします。

上記のワークフローには、いくつかの欠点があります。

• まず、プロダクトマネージャーがリクエストしてから製品化されるまで、とても時間がかかります。
• 開発者にとって、1ヶ月以上前に書かれたコードのバグに対処することは大変難しいことです。バグが発見されるのは、開発フェーズが終わり、QAフェーズが始まってからだということを覚えておいてください。
• ホットフィックスが必要な深刻なバグなど、緊急性の高いコード変更があった場合、できるだけ早くデプロイする必要があるため、QAフェーズは短縮されることが多々あります。
• 異なるチーム間での共同作業がほとんどないため、バグが発生すると人々はお互いを非難し始めます。誰もが自分のパートだけを気にするようになり、共通のゴールを見失ってしまうのです。

CI/CDは、自動化を導入することで上記の問題を解決します。バージョンコントロールシステムにプッシュされたコードの各変更は、テストされ、さらにステージング/UAT環境にデプロイされてさらにテストされた後、本番環境にデプロイされ、ユーザーに提供されます。自動化により、プロセス全体が…