明日の朝、たったひとつの小さな変更から始めよう
あなたは今、CI/CD、デリバリーパイプライン、内部プラットフォーム、継続的改善について読み終えたところです。素晴らしい内容です。しかし、自分のチームを見渡したとき、読んだ内容と実際の現場とのギャップが途方もなく大きく感じられるかもしれません。
もしかすると、ビルドプロセスはまだ開発者のノートパソコンで動いているかもしれません。リリースチェックリストは誰かの頭の中だけに存在しているかもしれません。ステージング環境は本番と大きく乖離していて、デプロイはギャンブルのように感じられるかもしれません。あるいは、まだチームすらなく、あなたとアイデアだけがある状態かもしれません。
そのギャップは正常です。今や安定したリリースを実現しているすべてのチームは、まさにあなたが今いる場所からスタートしました。彼らはある朝目覚めて、完璧なパイプラインが1日に10回のデプロイをゼロ障害で実行できるようになっていたわけではありません。彼らはそれを、一度にひとつの小さな変更を積み重ねて構築したのです。
本当のスタート地点
ほとんどのチームが抱えているのは、大規模な再設計を必要とするデリバリーの問題ではありません。彼らが抱えているのは、現在のプロセスの中で最も痛みを伴うたったひとつのステップです。そのステップこそが、あなたが始めるべき場所です。
今日、あなたのチームがどのように変更をリリースしているかを見てみましょう。誰かがコードを書き始めてから、ユーザーが新しいバージョンを使い始めるまでのすべてのステップをリストアップしてください。あるべき姿ではなく、実際に起こっていることに正直になりましょう。
- 誰がビルドを実行していますか？
- ビルドが成功したことはどうやって確認していますか？
- テストが失敗したらどうなりますか？
- 誰がデプロイしても安全だと判断しますか？
- 実際にどのように新しいバージョンを本番環境に投入していますか？
- 本番環境で正常に動作していることはどうやって確認していますか？
そのリストのどこかに、特定の誰かが何かを覚えていることに依存しているステップがあります。どこかに、同じ方法で二度と再現できないステップがあります。どこかに、リリースのたびに皆を不安にさせるステップがあります。
そのステップを選んでください。たったひとつで構いません。
ひとつの変更がどのようなものか
例えば、ビルドがまだ開発者のマシンで実行されているとしましょう。その開発者が休暇中だと、誰もビルドできません。彼らが微妙に異なるライブラリバージョンを使うと、ビルドの動作が変わります。彼らのノートパソコンがビルド中にバッテリー切れになると、チーム全体が待たされます。
以下は、そのスクリプトの最小限の例です：
#!/bin/bash
set -e
echo "リポジトリをクローンしています..."
git clone https://github.com/your-org/your-app.git
cd your-app
echo "依存関係をインストールしています..."
npm install
echo "ビルドを実行しています..."
npm run build
echo "ビルドが成功しました！"
これを build.sh として保存し、リポジトリにチェックインして、共有サーバーまたはCIサービスから実行してください。これで誰でも再現可能なビルドをトリガーできるようになります。
ひとつの変更：そのビルドを共有サーバーまたはシンプルなCIサービスに移行することです。派手である必要はありません。コードをプルし、ビルドを実行し、成功か失敗かを報告するだけの単一のスクリプトでも、ノートパソコンでのビルドよりはるかに優れています。これで誰でもトリガーできるようになります。結果が全員に見えるようになります。ビルドが再現可能になります。
あるいは、問題は別のところにあるかもしれません。ビルドは自動化されているが、デプロイはまだたった一人だけが知っている手動のSSHコマンドの連続である場合です。ひとつの変更：それらのコマンドをスクリプトに書き、リポジトリにチェックインし、CIシステムから実行します。これでデプロイが文書化され、再現可能になり、もはや記憶に依存しなくなります。
あるいは、ステージング環境が本番環境と一致しないことが問題かもしれません。ひとつの変更：両方の環境に同じデプロイスクリプトを使用します。スクリプトがステージングでは動作するが本番では失敗する場合、2つの環境の違いが可視化され、修正可能になります。
これらの変更には、新しいプラットフォームチームは必要ありません。高価なツールを購入する必要もありません。全員が完全なワークフローに同意する必要もありません。必要なのは、痛みを伴うひとつのステップを選び、それを少しだけ良くすることだけです。
スノーボール効果
最初の変更の後に起こること：それを実感できるのです。次のリリースが少しだけストレスフリーになります。次のビルドで「適切なノートパソコンを持っているのは誰？」というSlackメッセージを送る必要がなくなります。次のデプロイで、誰かがコマンドを入力するのを見守るための画面共有が必要なくなります。
その感覚が、次のステップを修正したいという気持ちにさせます。そしてその次のステップも。誰かに言われたからではなく、デリバリーの一部が予測可能になったときの感覚を味わったからです。あなたはもっとそれを欲しがるでしょう。
これが本当のCI/CD導入の進み方です。壮大な計画を通じてではありません。6ヶ月のプラットフォーム移行を通じてでもありません。時間とともに効果が積み重なる、小さく実用的な改善の連続を通じてです。
最初のステップを素早く見つける方法
この記事を閉じる前に、次のことを行ってください：
- アプリケーションのリポジトリを開きます。
- コードのコミットから本番デプロイまでのすべてのステップを、実際に今日行われている通りに書き出します。
- 最も痛みを伴うステップに印を付けます—最も頻繁に失敗する、最も時間がかかる、または最も暗黙知に依存しているステップです。
- 明日、そのステップを少しだけ良くするためにできる具体的なことをひとつ決めます。完璧ではなく、より良くするためです。
それがあなたのスタート地点です。
CI/CDの本質とは
すべての章、図、パイプライン、プラットフォーム、ガバナンスに関する議論を経て、これが核心の真実です：CI/CDとはツールのことではありません。完璧なパイプライン図を持つことでもありません。FAANG企業がやっていることを真似ることでもありません。
CI/CDとは、組織が変更をリリースし続ける能力のことです—アプリケーションコード、データベーススキーマ、インフラストラクチャに対して—安全に、そしてリリースのたびにそれを改善し続けることです。
その能力は買えません。インストールできません。コンサルタントが2週間のエンゲージメントで設定できるものでもありません。それは、今日のリリースを昨日より少しだけ苦痛の少ないものにしようと決意した人々によって、一度にひとつの小さな変更を積み重ねて構築されるものです。
明日の朝から始めましょう。ひとつのステップを選んでください。それをより良くしてください。そして、それを繰り返してください。