CI/CDを考える前にコードに共有の居場所が必要な理由
あなたは一人でアプリケーションを開発している。すべてのコードは自分のラップトップにあり、いつでも何でも変更でき、他の誰かの作業を壊す心配はない。シンプルでクリーンで、すべてがコントロール下にあるように感じられる。
そこに二人目のメンバーが加わる。すると、あなたとそのメンバーはそれぞれ自分のマシンにコードのコピーを持つことになる。あなたが金曜の午後にバグを修正したとする。チームメイトは月曜の朝に古いバージョンから作業を始め、うっかりあなたの修正を上書きしてしまう。どちらも何が起きたのか気づかず、誰かがバグが再発したことに気づくまで時間を浪費する。どちらのコピーが正しいコードなのかを突き止めるのに何時間も費やすことになる。
これこそが「とりあえずローカルに保存」が機能しなくなる瞬間である。
チームの拡大とともに成長する問題
実際のユーザーがアプリケーションに依存し始めると、状況はさらに悪化する。バグ修正、機能追加、ライブラリの更新、セキュリティパッチの対応が必要になる。これらの変更はすべて、調整された方法で行われなければならない。チャットメッセージやメールの添付ファイルでファイルをやり取りし続けるわけにはいかない。その方法は脆弱で、紛失しやすく、誰がいつ何を変更したかの記録も残らない。
共有システムがなければ、リリースのたびに手動での調整が悪夢となる。誰かが全員からコードを集め、手動でマージし、競合が発生しないことを願うしかない。このプロセスは疲弊し、エラーが発生しやすく、一貫して繰り返すことは不可能である。
ソース管理が実際に行うこと
ソース管理とは、チームメンバー全員がアクセスできるコードのためのストレージシステムである。シンプルに聞こえるが、その影響は計り知れない。
アプリケーションコードを保持する中央の場所が一つある。この場所をリポジトリと呼ぶ。チームメンバーは誰でもリポジトリからコードのコピーを自分のマシンにプルできる。変更が完了したら、その変更をリポジトリにプッシュする。リポジトリは各プッシュをコミットとして記録する。これは、特定の時点でのコードの状態を示すスナップショットである。
このシステムがあれば、チームは「最新バージョンは誰が持っている？」とか「どのファイルを変更した？」と尋ねる必要がなくなる。すべてがリポジトリに記録されている。コミット履歴を見れば、最新の進捗状況がわかる。
実用的なメリットはすぐに現れる。
- すべての変更が追跡される。 誰がいつ、何を変更したかがわかる。
- 元に戻せる。 何かが壊れた場合、履歴を確認して以前のバージョンに戻すことができる。
- 上書きがなくなる。 複数の人が同じコードベースで作業しても、誤って互いの作業を破壊することがない。
- 唯一の真実の情報源。 リポジトリに実際の最新コードが含まれているという合意がチーム内で成立する。
ソース管理がCI/CDの基盤である理由
ここがデリバリーパイプラインにとって重要な部分である。自動化パイプラインが実行される前に、どのコードを処理するかを知る必要がある。パイプラインはどこかからコードを読み取り、テストを実行し、アーティファクトをビルドし、サーバーに送信する必要がある。コードが個々のラップトップに散らばっている限り、これらは不可能である。
ソース管理は、パイプラインが信頼できる一つの場所を提供する。パイプラインはリポジトリからコードをプルし、処理し、出力を生成する。これが、ソース管理がCI/CDにとってオプションではなく、前提条件である理由である。共有リポジトリがなければ、自動化が機能するための唯一の真実の情報源は存在しない。
ソース管理がない場合を考えてみよう。誰かが変更を行うたびに、誰かが手動で全員からコードを集め、マージし、競合がないことを願う必要がある。このプロセスは遅く、信頼性が低く、自動化できない。結局、人間の記憶と手動の調整に依存するデリバリープロセスになってしまう。
実際のワークフロー
実際の流れは次のようになる。
- 自分のマシンでコードを書く。
- 行った作業を説明するメッセージとともに、変更をローカルでコミットする。
- コミットを共有リポジトリにプッシュする。
- 他のチームメンバーがあなたの変更を自分のコピーにプルする。
- リポジトリはすべてのコミットの永続的な記録を保持する。
このフローは、「ファイルを送って」とか「共有ドライブに保存した」という古いパターンに取って代わる。チームに信頼できる履歴と、コードベースで何が起こっているかについての明確な理解をもたらす。
次に来るもの
コードが共有リポジトリに置かれると、新たな疑問が生じる。進行中の変更をどのように管理するか？すべての変更を直接メインコードに取り込むべきではない。開発中の作業は、ユーザーが依存する安定したコードから分離する必要がある。
ここでブランチが登場する。ブランチとは、メインコードに影響を与えずに変更を加えることができる、独立した開発ラインである。隔離された環境で実験し、間違いを犯し、修正することができる。作業が完了したら、メインブランチにマージする。
ブランチはソース管理の次の自然なステップである。混乱なく並行して作業を進める能力をもたらす。ただし、それは別の記事のトピックである。
実践的なチェックリスト
CI/CDパイプラインを設定する前に、以下の基本が整っていることを確認する。
- すべてのアプリケーションコードが、チームメンバー全員がアクセスできる共有リポジトリにあること
- チームメンバー全員がプル、コミット、プッシュの方法を知っていること
- コミットメッセージが「修正」や「更新」だけでなく、何をなぜ変更したかを説明していること
- チームが安定した本番環境対応コードを表すブランチについて合意していること
- リポジトリへのアクセスが制御されていること（誰もが直接メインブランチにプッシュできるわけではない）
まとめ
ソース管理は「あると便利」とか「ベストプラクティス」といったものではない。信頼できるデリバリープロセスの基盤である。ソース管理がなければ、チームは機能を構築するよりもコードの調整に多くの時間を費やすことになる。ソース管理があれば、チームと自動化の両方が信頼できる唯一の真実の情報源を手に入れられる。パイプラインやデプロイ戦略、その他のCI/CDの部分を心配する前に、まずここから始めよう。