CI/CDとは
CI/CDとは「Continuous Integration／Continuous Delivery」の略で、「継続的インティグレーション／継続的デリバリー(デプロイメント)」といいます。
簡単に「自動テスト・自動デプロイ」とも言えます(簡単すぎかも)。厳密な定義はなく、「継続的インテグレーションと継続的デリバリーの流れ」を指すこともあれば「継続的インテグレーション、継続的デリバリー、継続的デプロイメントまでの流れ」を指したり、継続的デリバリーに継続的デプロイメントを含む意味合いで使われることもあってややこしいです。
CI/CDの仕組みを作ることで工数を大幅に削減したり、属人化を防いだり、バグの精査漏れを防いだりと最近では欠かせないものとなってきています。
CI
継続的インテグレーションの一つの要素として「開発におけるブランチの競合を解決する」ことがあげられます。
例えばとあるアプリケーション開発のオープンソースプロジェクトがあるとします。AさんとBさんはそれぞれ別の追加機能を実装し、たまたま同じ時間にデプロイしました。そうすると互いのコードは競合します。競合後は互いのコードをテストしながらマージしていくわけですが、これがもっと大人数で行われたり、頻度も高く行われるとテスト量は果てしないことになります。このテスト部分を自動化してしまおうというわけです。
開発者による変更がアプリケーションにマージされると、 自動的に単体テストや統合テストが行われ、自動でアプリケーションの正当性をチェックすることで簡単にバグを見つけ、修復を楽にします。
CD
継続的デリバリーでは継続的インテグレーション内で行われたテストの後にビルドされ、テスト用のサーバーにデリバリーされ、すぐに動作確認を行います。その後、継続的デプロイで本番環境へのデプロイが行われます。本番環境へのリリースの判断は自動化せず人間が介入する場合も多いです。
実装
実際に実装したものを簡単に紹介します。APIとして機能するLambdaのソース変更からデプロイまでのサイクルです。
開発者がdevブランチにマージした際、GitHub内ではGitHub Actionsが動きテストを行います。pythonを使っていたのでpytestを使用しました。
単体テストに問題がない場合、開発者はdevブランチからmain(master)ブランチへとマージします。
mainブランチのソース変更が行われるとAWS Codepipelineが発火します。ソースステージではGitHubから更新されたソースを取得します。
ビルドステージではコンパイルやテストを行います。当時はpythonでコンパイルが不要だったのと、GitHub Actionsでテストを行ったのでビルドステージでは特に何も行わなかったような気がします。(code buildで統合テストとかもできると思うのでやってみよう)。
最後のデプロイステージではcloudformationを使いLambdaにデプロイします。
このように今までは人が全て手動で行ってきたプロセスを自動化することで効率は格段にあがります。