あえて確認をしないようにする輩

ある開発案件で、CI/CD のルールを検討していて、

  1. feature ブランチからのプルリク作成時にユニットテストを実行する
    • プルリク作成後はコミットがあるたびにユニットテストが再実行される
    • ユニットテストが成功していない状態では、管理者でもマージはできない
  2. プルリクをマージする時に再度ユニットテストを実行する

というようなルールを考えていたら、

とツッコミが入った。コレに対して理解が得られなかったので愚痴る。

確かに、上の条件なら、ほぼ確実に「全く同じユニットテストを2回行う」ことになるだろう。

だが自分は、「いざマージしてみたらアプリがビルドできなくなっていた」という障害を経験したことがある。それは複数ブランチのプルリクをほぼ同時にオートマージしたことで発生したものだった。それぞれのプルリクがマージ可能な状態で、2窓開いて同時に「マージ」ボタンを押せば、それは容易に再現できる内容だった。

つまり、マージの前後で、ソースコードが全く同じではなかったのだ。ツールがうまいこと制御してくれているつもりでも、なんらかの抜け道が出来てしまったら、問題が起こるワケだ。

このようなバグの再発を防ぐには、「マージ後に改めてユニットテストが通るかチェックし、通らなければ何かおかしいのだから通知する」という対策が思いつくのは自然なことだろう。

それに、もし仮に、今回選定したツールではそうした「複数ブランチで同時にマージ処理」みたいなことをしても、問題が起こらないように制御しきっているとしよう。

それでも、だ。

それでも、「もしそこで問題が起きていたらすぐに知りたい」ことがあるなら、いつ・何度でも再確認したらいいんじゃない？ と思うワケだ。

今回なら、「マージ先のデフォルトブランチ」は、常にユニットテストが通る状態であることを担保したい要件があるので、だったらマージ後であっても、ユニットテストが通るかチェックするべきなのである。

なんなら、プルリクやマージがなくても、毎日1回必ずユニットテストを行うという定期処理を組んだって、全く問題ないし、望ましいことだとすら思う。

これは契約プログラミングでいうところの「不変条件」に近い話なのだから、事前・事後の両方で同じチェックを行って、「事後チェックの意味があまりない気がする」状態で正しいのだ。

しかし指摘者の考えは違った。

「毎回同じ結果になる『はず』だと『想定』できているから、そんな無駄なことやる必要はない」

そう思っているのだった。

ツールが 100% 確実に割り込み処理をハンドリングしてくれる、ヒューマンエラーが起こらないようツールで制限している、それなら想定外の事態は起こり得ないはずだ、と考えているのだ。

言いたいことは分かる。自分だって、大抵の場合はそう思う。でも、想定外の事態は事前に想定できていなかったから起こるモノなのだ。今の時点で、問題が起こるパターンが見えないから、何の対策もしなくていい、というのは、いささか思慮が甘いと言わざるを得ない。

「コードを変えていない状態で、毎日1回ユニットテストを行う？そんなの結果が変わるワケないじゃん、無駄じゃね？」

本当にそうだろうか。

(今回の話の中では「ユニットテスト」と表現しているが、もう少し大規模なテストを CI/CD で定期実行したら、また違ったことになる。例えば、実行日に依存するテストをやってみたら月末だけ起こるバグに気が付いたとか、テストの失敗からネットワーク連携している相手システムの仕様変更に気付いたとか)

本当に結果が変わるワケないのだと思うなら、それを証明するために、毎日テストをやって確認してもいいよね？あえてやらないことにすることでのメリットって、なんかある？

無料で使える CI/CD ツールが毎日1回テストを実行したところで、コスト的な問題はないのだし、どうしてその確認を怠っていて自信が持てるのだろうか。

自分は今日一日外出していないから、家の鍵は閉まっているはずだ、といって、就寝前に戸締まりをチェックしない人がいるだろうか。もしかしてそういう人は、戸締まりを確認しないモノなのだろうか。僕はエンジニア職になるよりはるか前から、戸締まりは毎日必ず確認する人間だった。

正しさが重要な画面なら、何度だって確認したらいい。

結局今回の場面では、「『僕の提言を上長が確認して却下した』という記録を文面を残しておいてもらえるなら、マージ後にテストをやらないルールで良いですよ」と決着を付けた。あとでトラブルが起きた時に、設計担当の僕は正しく、レビュアーである上長が間違っていた、と客観的に明らかにするためだ。自衛は大事。

過去にも似たようなこと言ってるからさ、もうみんないい加減にしようよ。成長して。