CI/CDとは? 初心者にやさしい解説
CI/CDとは、コードが変更されるたびにソフトウェアのbuild、テスト、出荷を自動的に行い、releaseを小さく、頻繁で、退屈なものにする実践です。
CI/CDは継続的インテグレーション (continuous integration) と継続的デリバリー (continuous delivery、またはdeployment) を表します。この2つが合わさって、コードの変更を開発者のノートPCからユーザーまで届ける自動化された道筋を、各ステップでのチェックとともに描きます。大規模なチームがどうやって1日に何十回も出荷しながら全体を壊さずにいられるのか疑問に思ったことがあれば、その答えがCI/CDです。
CI/CDが実際に意味するもの
"CI"の部分、すなわち継続的インテグレーションは、開発者が自分の作業を共有コードベースに頻繁にマージし、すべてのマージが自動的にbuildとテストにかけられることを意味します。"CD"の部分、すなわち継続的デリバリーは、コードがそれらのテストに通ったら自動的にrelease向けに準備され、deployが危険なイベントではなく日常的なボタン操作になることを意味します。一部のチームはさらに継続的デプロイメントに進み、通過したコードは人間のゲートなしに本番へ出荷されます。
CI/CD pipelineの仕組み
- 開発者がcommitをpushするか、pull requestを開きます。
- CI serverがコードをチェックアウトしてbuildを実行します。
- 自動テストが実行され、コード品質やセキュリティのチェックも実行される場合があります。
- すべてが通れば、artifact (パッケージ化されたbuild) が生成されます。
- 継続的デリバリーがそのartifactを各環境で昇格させ、最終的に本番に至ります。
簡単な例
小さなWebアプリを想像してください。開発者がタイプミスを修正し、pull requestを開きます。1分以内に、pipelineが依存関係をインストールし、ユニットテストを実行し、PRに緑のチェックを報告します。チームメイトがレビューしてマージします。マージはstaging環境へのdeployを引き起こし、smoke testがサイトの読み込みを確認し、変更が本番へ昇格されます。すべて誰も手動でコマンドを実行することなく行われます。
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm testチームがCI/CDを採用する理由
手動のbuildとreleaseは遅く、エラーが起きやすいものです。CI/CDはバグが導入されてから数分以内に、最も修正コストが安いときに捕捉し、releaseを推論できるほど小さく保ちます。より小さく頻繁なreleaseは、変更あたりのリスクを減らし、何かがうまくいかなかったときの回復を速くします。自動化はまた、エンジニアを反復的なrelease作業から解放します。
runnerが登場する場所
pipelineは実行するマシンを必要とし、それはrunnerまたはbuild agentと呼ばれます。その速度、信頼性、コストが体験全体を形作ります。遅かったり不安定なrunnerはCIを税金のように感じさせます。Latchkeyのようなマネージドrunnerプラットフォームは、そのレイヤーを速く信頼できるものに保ち、pipeline自体が邪魔にならないようにすることを目指しています。
重要なポイント
- CI/CDはコード変更ごとにbuild、テスト、releaseを自動化します。
- CIはバグを早期に捕捉し、CDは出荷を日常的で低リスクにします。
- その結果、releaseはより小さく、より頻繁で、より信頼できるものになります。