第一回：CI/CDの基本と全体像
CICDとは何か、なぜ重要なのか？
CI/CDという言葉は耳にする機会が多いですが、その本質を理解しているでしょうか？CI/CDとは、継続的インテグレーション（Continuous Integration）と継続的デリバリー/デプロイメント（Continuous Delivery/Deploymentを合わせた概念です。
簡単に言えば、開発者が書いたコードを自動で検証し、品質を保ちながら、いつでもリリース可能な状態にすることを目指します。
「昭和」な開発からの脱却
「CI/CDなんてしなくても、手動でやればいい」という声が聞こえてくるかもしれません。しかし、手作業には以下のような大きなリスクが潜んでいます。
- ヒューマンエラー: 手作業によるビルドやデプロイはミスが起きやすく、予期せぬトラブルにつながります
- リードタイムの長期化: テストやデプロイに時間がかかると、新しい機能をリリースするまでの期間が長くなります
- コードの品質低下: 誰もがコードに触れることを恐れるようになり、リファクタリングや改善が停滞します
CI/CDを導入することで、これらの課題は解決します。コードが変更されるたびに自動でテストが実行され、バグを早期に発見できます。常にクリーンなコードが保たれ、いつでも安心して本番環境へデプロイできる状態になります。
さらに、CI/CDは単なる自動化を超えた価値をもたらします。それは、開発チームの心理的な安全性を高めることです。「ここを直したら、他の部分が壊れるのでは？」という不安から解放され、エンジニアは積極的にコードの改善に取り組むようなります。古いフレームワークや技術スタックの置き換え、新しい開発手法の導入、ライブラリのバージョンアップといった、これまで手をつけにくかった作業にも、安心して挑戦できるようになります。
常に新しいコードでテストが実施されるため、開発者は自信を持って新しい技術を試すことができ、結果としてプロダクトは常に最高の状態に保たれます。これは、未来志向の開発スタイルへの大きな一歩となるでしょう。
今回のパイプラインの全体像
本記事では、Pythonで開発したアプリケーションをDockerコンテナとして動かし、GitLabとAWSを組み合わせてAWS環境に自動デプロイするための、実践的なCI/CDパイプラインを構築します。このパイプラインは、コードの品質とセキュリティを徹底的に検証し、最終的に本番環境に安全にデプロイすることを目的としています。
このパイプラインは、開発者のPCからデプロイが完了するまでの全プロセスを、以下のように自動化します。
1. 開発者の作業（ローカル環境）
CI/CDは開発者のローカルPCで自分専用のローカルリポジトリに対する作業からはじまります。
- Git pull/ checkout: 最新のコードをリポジトリから取得し、作業ブランチに切り替えます
- Git add/ commit: コードの変更をステージングエリアに追加し、ローカルリポジトリにコミットします
- pre-commit: この時点で、pre-commitフックが実行されます。これはローカル環境で自動的にコードのフォーマットチェックや基本的な静的解析を行う仕組みで、開発メンバー全員が利用するリモートレジストリに不整合なコードがコミットされるのを防ぎます
2. GitLabでのパイプラインステージ自動化（CI/CD）
開発コードがリモートリポジトリにマージされると、GitLabのCI/CDパイプラインが自動的に動き始めます。
- Git push: コミットされたコードをリモートリポジトリにプッシュします
- Merge Request / Approve: 機能開発が完了すると、マージリクエスト（MR）を作成します。チームメンバーがコードレビューを行い、承認を得た後、メインブランチにマージします。このタイミングで、CI/CDパイプラインが実行されます
- Git tag: リリースするコードにタグを付与します。このタグをトリガーに、後続のデプロイプロセスが開始されます
- Build & Unit Test: コードをビルドし、単体テストを実行します
- Clean Build & 保存: クリーンビルドを実行してテスト関連の依存関係のないクリーンなDockerコンテナイメージを作成します
- 静的解析: 静的解析ツールを利用してコードのバグや品質の問題を自動で検出します
- 脆弱性診断: 登録されたコンテナイメージに対して脆弱性スキャンを実施します
- AWSへのデプロイ: テストとセキュリティチェックを通過したDockerコンテナイメージを、GitLab RunnerがAWS ECRにプッシュし、ECSタスクへのデプロイを更新します
これらの処理は、GitLab Runnersと呼ばれるプログラムがGitLabのサーバ上で動作し、CI/CDパイプラインの各ステップを実行する役割を担います。CI/CDパイプラインの処理内容はソースコードのリポジトリのRootディレクトリに配置された.gitlab-ci.ymlファイルにYAML形式で定義されることとなります。
この一連の流れを図にすると、以下のようになります。
このように、一連の流れを自動化することで、開発者は本来の業務である「価値のあるコードを書くこと」に集中できます。
次回予告
次回は、本パイプラインの具体的な構築手順に入ります。まずは、CI/CDの心臓部である.gitlab-ci.ymlファイルの基本的な書き方から始め、ローカルでのpre-commitフックの設定方法と、GitLab CI/CD上でのビルド・テストの自動化について詳しく解説します。