はじめに

CI/CDってのは「コミットしたときにテストを自動的に走らせること」ではない
システム開発のボトルネック・一番課題になりやすいコードの統合・リリース作業を「小さく」「高頻度で」「自動的に」行うことが市場提供を早めるという話。

参考書籍

結局はこれを読めという話でしかないけど。
分厚いけど、どれもこれも勉強になるのですごい。
このボリューム全部勉強になるってどういうこと？
自分でQiitaに記事書いて、自分で読み返して、しょうもないなと思うことが何度もあるのに、この文量で全部勉強になるとか何？神？

自分の誤解

CI/CDツールとして「Jenkins」が紹介されてるのをみる。
「Jenkins」を導入するのがCI/CDだ！みたいなLTをたくさんみる。
自動テスト=CIだと勘違いする

CI/CDが解決したがっていること

ソフトウェアのデプロイが手動で毎回リスクが伴う。（もっとも重要でそこでミスったらまずいところなのに、頻度が少ないというだけで、そのリスクを放置している）
開発環境・テスト環境・疑似本番環境・本番環境でのデプロイ手順どころか関係者も含め全て異なるため、本番環境でのデプロイは本質的には毎回ぶっつけ本番になっている。
ちょっとした修正だから本番環境をその場で直した。システムダウンからフォールバックしたらその設定が消えた。

CI/CDで重要な概念

個人的な抜粋です。

システムは「小さく」変更すること
開発者へのフィードバックを「高頻度」にすること
間違ってはいけないものは「自動化」すること

小さく変更する

大きな変更の弊害
大きく変更する＝ビッグバンマージと表現されるケースもあります。
500のコミット・1000行の変更が含まれたマージリクエストがあったとします。

これをマージした結果、不具合が発生しました。
以前のバージョンでは発生していなかったバグです。

そうなると不具合は500のコミット・1000行の変更のどこかが原因になっています。
他の機能追加も含めてフォールバックになるでしょう。
それによるビジネス的な損失もありますが、開発者としてここからバグを探すのは苦しいでしょう。

小さな変更の利点
1のコミット・1行の変更が含まれたマージリクエストだとします。
これで不具合が生じても原因箇所も明確ですし、他の機能も影響しないでしょう。

具体的なテクニック
「フィーチャーフラグ」や「抽象的なブランチ」といった戦略があります。
イメージ的には新しい機能は if false で囲って実装する感じです。
まぁマジで if false で囲うとテストすらできないので、あくまでイメージでしかないですが。

詳しいところは一つのテクニックでも説明大変なのでここでは割愛。

高頻度のフィードバック

年一回のリリースの弊害
すごく大変でも年一回なら改善しません。
変更を加えてしまった時の影響が大きいからです。
１年分の変更をおじゃんにしてしまう可能性があります。
それなら多少手間でも以前の手順に従うでしょう。

高頻度のリリースを実現する
何度もやることになる。しかも影響が小さいのであれば色々とチャレンジすることができるでしょう。
高頻度化は、改善にチャレンジするハードルを下げる効果もあります。

何度もチャレンジできるのであればその分改善も進みます。
開発者がチャレンジしやすくさせ、フィードバックを受けやすくするためには高頻度化は良いアプローチだと思います。

具体的なテクニック
概念的なものはいくつか冒頭の書籍でも紹介されていますが、リリース作業などは現場によっても大きく手順が違うと思うので、それぞれの現場で見つけるしかない。。。

そもそも多くの現場ではリリース作業というのは負荷が高いと思います。
自動化を行うことで負荷を下げていく話はあるんですが、最初は大して負荷下がらないと思います。

最初の一歩は諦めることです。
「効率よくリリースしよう」なんてことは諦める。
無駄に何度もリリースしましょう。
そうやって改善するしかない。

上司を説得できない？
冒頭の本を渡しましょう。
読め。話はそれからだ。

自動化する

手動リリースの弊害
障害の一時対応として入れた変更が、開発環境やテスト環境に入ってなくて新たな障害を呼び起こすことはよく聞く。
なんならそのままにしてたのを忘れてて、本番壊れてバックアップからリストアしたら、設定がなくなって古の障害が呼び覚まされるとか。
割と簡単に想像はできる。でもスピード優先でやる現場は何度も経験してきた。

自動化へのロードマップ

どの環境のリリースも手順を同じにする。（環境差異は環境変数でカバーしたい）
どんな資材のリリースも手順を同じにする。（資材によって違う部分は自動化して隠蔽していく）
人じゃなくていいところは自動化していく。
リリース後の検証も自動化していく。

そんな感じ。

まとめ

「CIはコミットしたときにテストが走ること、CDはコミット同時にリリースされること」という理解は浅すぎるぞ自分。
大事なのは「小さい」「高頻度」「自動化」がキーワードだ。
お前の現場に合うCI/CDの形はお前が見つけるしかない。がんばれ自分。

次回予告

本記事は、2022アドベントカレンダー「受託アジャイル」の記事です！他にも興味あれば見てってください。
次回は、TDD導入の四苦八苦です。