導入
この記事は、長年働いてきた私の CI/CD に関する理解であり、純粋に個人的な意見です。
概念的なことはあまり話さず、技術者が実際に触れることができるプロセスから直接話していきたいと思います。さらに、この記事ではいくつかの一般的なプロセスに焦点を当てたいだけであり、詳細の違いについてはここでは触れません。たとえば、マイクロサービスの CI/CD はモノリシック サービスの CI/CD とは若干異なり、コンテナーやk8 が関与する場合には違いが生じます。ここではそれについては話しません。
CI は継続的インテグレーションを指し、CD は継続的デプロイメントを指します。通常、これらのプロセスには次のものが含まれます。
コードステージ
コード ノードは開発段階とも呼ばれます。この段階では通常、コードをローカルで開発します。この段階ではまず、idea、vscocode などのいくつかの開発ツールが必要になります。
同時に、git などの一般的に使用されるコード ホスティング ツールも必要になりますが、もちろん git の使用に制限はありません。
最後に、もう 1 つの非常に重要ですが見落とされがちなリンク、それはコード レビュー (略して CR) です。言うまでもなく、CR の重要性は多くの外資系テクノロジー企業で必須のプロセスです。中国では近年CRへの注目が高まっているように感じますが、私が以前いた会社ではCRがないとテスト環境にコードを公開できませんでした。
crステージで使用するツールに関しては、各社で異なるのが一般的です。idea for cr などの開発ツールを直接使用している人や、gitlab for cr などのホスティング ツールを使用している人も見かけました。大企業の中には独自の cr ツールを持っている人もいます。しかし、ツールは重要ではなく、重要なのはプロセスです。
コンパイルフェーズ
コンパイルフェーズはビルドフェーズとも呼ばれます。まず、通常、依存関係の問題が考慮されますが、たとえば、Java コードをコンパイルする場合、jdk のバージョン、pom の依存関係などを解決する必要があります。
2つ目の注意点は単体テストですが、コンパイルフェーズでは開発フェーズで書いた単体テストコードが自動的に実行されるのが一般的です（もちろん自分で書いたことが前提ですが、笑）。同時に、単体テストでは一定のカバー率を確保する必要があり、カバー率が低い単体テストは意味がありません。そのためには、単体テストを書くという良い開発習慣が必要です。あらゆる種類の単体テストはこの記事の焦点ではないため、ここでは示しません。
コンパイルも問題なく、単体テストも問題なく、概ねビルド、パッケージ化してテスト環境にリリースできます。パッケージ化と公開に一般的に使用されるツールは jenkins です。コンテナーのデプロイメントが関係する場合、通常、この段階でサービスのイメージもパッケージ化し、ミラー ウェアハウス (プライベート ウェアハウスまたはパブリック ウェアハウスの場合があります) をプッシュします。
テスト環境
サービスをテスト環境にパッケージ化した後、通常はテスト環境で統合テストを実行する必要がありますが、いわゆる統合テストとは、インターフェイスに従ってプロセスを統合したり、特定の機能をテストしたりすることです。たとえば、注文のプロセスには多くのモジュールが関与する可能性があり、注文のプロセスのテストは統合テストです。
本番環境
実稼働環境には多くのリンクが関係しており、最も重要でもあります。結局のところ、これは最終的な配信リンクであり、これまでのすべての作業はこのステップの準備のためのものです。
実稼働環境にリリースする場合、通常はすぐに全量をリリースするのではなく、最初にグレースケール デプロイメントを行います。グレースケール展開とは、運用環境のトラフィックを古いバージョンから新しいバージョンに段階的に切り替えることを指します。通常、トラフィックは比例的に分散されます。たとえば、リクエストの 90% は古いバージョンに送信され、10% は新しいバージョンに送信されます。その後、問題が見つからない場合は、新しいバージョンのトラフィックを徐々に拡大し、古いバージョンのトラフィックを減らします。
これにより、障害の影響が最小限に抑えられます。
グレースケール パブリッシングには多くのソリューションがあります。たとえば、フロントエンド CDN テクノロジを介した、より多くのバックエンド ソリューションがあります。たとえば、nginx に基づいています。コンテナに基づいてデプロイする場合は、k8s イングレスを通じてグレースケール パブリッシングを実装できます。
グレースケール検証後に問題がなければ、通常はネットワーク全体に公開できます。これまでにさまざまなテストが行われてきましたが、一部の問題はトラフィックが多いときにのみ顕在化する可能性があるため、完全リリース後に問題がないという保証はまだありません。そのためには、オンラインで問題が発生したときにすぐに以前のバージョンにロールバックできるように、ロールバック メカニズムが必要です。
もう 1 つの焦点は、サービスがオンラインになった後の継続的な監視と、問題に対するタイムリーな警報メカニズムです。これには通常、Prometheus などのサードパーティ監視ツールの助けが必要です。