継続的インテグレーション（CI）実践のポイント

はじめに

この記事では、「継続的インテグレーション（CI）実践のポイント」について書いています。

DevOps勉強の中の一つとして継続的インテグレーションについて調べ記事に書いてみました。

自分に向けた備忘録でもありますが、「継続的インテグレーション（CI）は何に気を付けて実践すれば良いのか知りたい」な人の一助になれば嬉しいです。

本文

  • メインラインに頻繁にコミットする
    • メインライン = メインブランチ、トランク。ブランチの作成元のこと。
    • 自動ビルドの環境を構築しても、頻繁にコミット/マージする文化がなければ、何の役にも立たない
    • 仮に開発者が3週間コミット/マージをせず、そしてコミット/マージ後ビルドが壊れた場合、どこで壊れたかを突き止めるのに、3週間分の作業を調べなければいけなくなる。
  • ブランチはできるだけ少なくし寿命も短くする
    • ブランチがたくさんあるとそれだけ運用が複雑になり、コミット/マージ作業も煩雑になる
    • できるだけブランチは少なくする（究極はトランクベースの開発）
    • ブランチがある場合も、少なくとも1日に1回、できれば変更のたびにトランクにコミット/マージする必要がある。
    • そのためにフィーチャートグルなどを利用することもある。
  • ビルドを自動化する
    • 実施しやすい項目だが注意が必要
    • 自動化していてもスケジュール的（例えば夜間だけビルド）でコミット/マージの度には行っていない場合がある。
    • また、各ビルドをテストまたは検証していない場合もある。
    • ビルドを検証していなければ、継続的インテグレーションを行っているとは言えない。
  • ビルドに対してテストを組み込む
    • ビルドを検証するための段階として、、、
      • 第一段階は、問題があるビルドは確実に失敗すると分かること。
      • 第二段階は、ビルドの成果物が動くかどうか、期待どおりに動作しているか判断できることです。
    • これらテストは、ビルドプロセスの一部として含める必要があり。
  • ビルド時間を出来るだけ短くする
    • ビルドに時間がかかりすぎると、開発者は頻繁に変更をコミットすることを嫌ったり、変更をまとめてコミットするようになる。
    • こうなってしまうとエラーの原因をすばやく突き止めるのが不可能になる。
    • また実行に時間がかかると、その間にさらに何十件もの変更が発生する可能性があり、問題をすばやく見つけるのが難しくなる可能性もある。
  • クローンでのテスト
    • 検証は本番環境（意図した環境）でソフトウェアが期待行うこと。
    • 別の種類の環境でテストすると、結果が間違っている可能性がある。
  • 壊れたビルドをただちに修正する
    • ビルドに問題があった場合、開発チームが問題を早急に見つけ出し、ただちに修正することが重要。
    • CIは、ビルドが検証され、継続的にコミットされるプロセスを構築します。
    • そのため、何か問題が生じた場合も、修正するのは簡単です。

おわりに

「継続的インテグレーション（CI）実践のポイント」について解説しました。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

https://notepm.jp/blog/6932

https://cloudbees.techmatrix.jp/blog/7-ways-know-youve-aced-continuous-integration/

https://www.jetbrains.com/ja-jp/teamcity/ci-cd-guide/continuous-integration/