GitHub Actionsの検査を見直す前に、CI/CDの流れを整理した

変更のたびに動く検査が気になり、回数を減らす方法を考え始めました。ところが、先に必要だったのはCI/CDの流れを理解することでした。何を、どの版で、いつ確かめるかを整理した記録です。

「前に通った」は、どこまで使えるのか

commitはコードの版を記録し、pushは変更を送ります。その操作だけで、検査に合格した証明が付くわけではありません。手元で通った結果にも、対象のコード、依存、設定、環境、実行範囲という条件があります。

共通関数を変えれば、直接編集していない利用側へも影響し得ます。変更行だけを調べれば十分とは言えません。一方で、すべての変更に全量検査を繰り返すと決める前に、影響範囲と過去の結果を使える条件を確かめます。

約3時間かかったTestの実例もありました。ただし、それは確認できた1回です。頻度や平均、費用は未確認で、例外的かどうかもまだ判断していません。

CI/CDを、Actionsの外側から見る

CIは小さな変更を頻繁に統合し、検査から早くフィードバックを得る習慣です。GitHub Actionsは、その処理を実行する仕組みの一つです。CDには、公開可能な状態を保つContinuous Deliveryと、条件を満たした変更を自動で本番へ出すContinuous Deploymentがあります。

編集と手元確認から、commit、push、PRでのCI、レビューと統合、共有版のCI、公開候補の検証、公開、公開後の確認へ進みます。PRは流れの一例で、すべての開発で同じ形を使うとは限りません。

以前の結果を再利用するには、対象版・入力・環境・必要な検査範囲が一致している必要があります。統合後や公開後の段階には、その時点でしか確かめられないこともあります。

減らす前に、何を守る検査かを決める

まとめてpushすれば、push回数を減らせることはあります。ただし、多くの変更が一度に入ると、失敗箇所を探す範囲も広がります。手動実行も選択肢ですが、公開を止める必須チェックと、任意の重い検査を分けて設計する必要があります。

未実行と実行済みの成功を区別し、どの版の結果で判断したかを残す。公開の前後には必要な確認を置く。こうした原則は共通にできますが、言語や製品、実行環境まで同じ検査にそろえる必要はありません。

最初にAIへ作らせた説明では、一般的な流れが抜けていました。その説明を補って初めて、自分が何を省こうとしていたのかが見えてきました。今回は棚卸し、考え方の整理、変更案と静的な確認までです。製品のworkflowへ適用した結果や、時間短縮、本番受入を実証した記事ではありません。

もっと深く読みたい人へ

全文では、最初の疑問から判断が変わった過程と、Git・GitHub・DORAなどの一次資料をたどれます。