継続的インテグレーションとは
継続的インテグレーションとは、「ソフトウェア開発の品質改善プロセスを自動化すること」で、
特に、開発者がソースコードをコミットし共有しているリポジトリに統合するだけで、「ビルド」と「テスト」が自動的に実行される手法のことを言います。
継続的インテグレーションにより、ソフトウェアのバグを早期に発見し対処することができるため、チーム開発のスピードを上げコードの品質を保証することが可能となります。
継続的インテグレーションは自動ビルド、テスト、インスペクションなどを継続的に実施するためのプラットフォームであり、DevOps と呼ばれるソフトウェア開発手法の1つである。 継続的インテグレーションを実施することで、上記のような効果を得られる。継続的インテグレーションのポイント
以下が継続的インテグレーションを行うポイントとなる。
なぜ継続的インテグレーションが必要か
継続的インテグレーションは導入前と導入後でのチームの反応が大きく異なることが多い。
導入前、継続的インテグレーションに対する期待値はとても低いが、いったん導入すると継続的インテグレーションが持っている影響力に驚き、プロジェクトにとって必須のツールとなる。
導入後、コミットする度に自動ビルドとテストが開始され、問題が即座に発見されることになる。
この「問題が紛れ込んでから発覚するまでの時間」が短ければ短いほど、原因を探す範囲が狭くなるため対応する時間が減少する。
ソフトウェア開発チームにとってバグを作ったとしても対処するための仕組み(継続的インテグレーションの導入)があることで安心して開発に取り組むことが可能である。
継続的インテグレーションを導入しようとするとき、チームは新たに追加されるルールやプラクティスを嫌うかもしれない。
目に見えて効果がすぐにあがるツールではなく、開発現場の問題を全て解決してくれる「銀の弾丸」ではない。
しかし、継続的に繰り返す自動ビルトとテストを自動化するために少しの時間を割くことで自分たちの仕事をより面白く生産的にすることができる。
継続的インテグレーションのメリット
継続的インテグレーションが実行することはとてもシンプルで地味な仕事である。
開発者がソースコードを頻繁にコミットする、その都度、継続的インテグレーション(自動ビルド・テスト)が自動実行される。
地味ではあるが、これを人力でやろうと思うと大変だ。しかし地味な作業も以下のような、とても大きなメリットに繋がる。
- バグを短時間で発見し、対処することが可能
- チームの生産性と効率アップ
- 品質の高い、安定した製品のリリース
コミットの度に自動ビルドとテストが実施されるため、問題の発見にかかる時間が最小になり、すぐに対処することが可能である。大きな問題になる前の小さな問題の内に対処が可能である。
開発者はバグ対応にかける時間を短縮し、機能の追加により多くの時間を費やすことができる。チームに開発に集中できるという安心感をつくる。
開発者がお客様に素早く安定した品質のソフトウェアをリリースすることができる。顧客満足につながり、開発者にとってもリリースに対する自信となる
継続的インテグレーションのベストプラクティス
継続的インテグレーションは開発チームにとって品質を担保するための最後の砦になっていく。開発者のどんな小さな修正に対しても自動ビルドとテストを継続的に実行することでソフトウェアが常に正しく動作することを保証する。品質を見える化することにより、チームが開発しているソフトウェアは継続的インテグレーションの最新履歴を見ればわかるようになる。
継続的インテグレーションを効果的にするためのベストプラクティスがある。
- 頻繁にコードをコミットする
- ビルドが失敗したコードはコミットしない
- 失敗ビルドは早急に修復する
- 開発者による単体テストを自動化する(テストを書く)
- すべてのビルドとテスト合格(オールグリーン)にする
- プライベートビルド(開発環境)を実行する
- ビルドが失敗したコードを取得しない
(※継続的インテグレーション入門より)
継続的インテグレーションの環境とツール
ソフトウェア開発チームに継続的インテグレーションを導入するために必要な環境は、大きく分けて3つある。
- コードの保管場所(リポジトリ)
- コードのオーケストレーションツール
- フィードバック通知と監視
ソフトウェア開発チームにとって必須のツールです。開発者がコードを作成し、コミットするためのバージョン管理システムである。GitやSubversionなど。
※苦手な方は、ぜひ当サイトのチュートリアルで学んでみてください。
継続的インテグレーションの核となるツールである。開発者がコミットするとそれをトリガーとして継続的インテグレーション(オーケストレーションツール)がビルド、インスペクション、テスト、デプロイを自動化する。
結果を素早く知ることが早期に問題を解決に繋げる。継続的インテグレーションの結果を開発者に通知する。Chatサービスやメールサービスなどを利用。
コードのオーケストレーションの中心的な役割を担うのが継続的インテグレーションである。
オーケストレーションでは、自動テスト、オールグリーンになったソースコードのデプロイ、ステージング環境や本番環境の設定、本番サーバーのセットアップなど継続的な展開が可能である。これは継続的インテグレーションを拡張した「継続的デリバリー」として説明する。
継続的インテグレーションの5つの指標
継続的インテグレーションの導入により、開発チームにとって開発のパフォーマンスが向上したのか、製品の品質に繋がる改善ができているのかを知ることが重要である。
ソフトウェア開発のライフサイクルを改善するためにライフサイクルを構成するプロセスを測定する。プロセスの変更がどのような結果になったかを把握するためである。
- パイプライン時間
コードのコミットからデプロイにかかる時間 - ビルド時間
テスト実施、必要なテストの準備時間も含む時間 - エンジニア待ち時間
ビルド実行までのエンジニアの待ち時間 - masterブランチ の障害時間(Subversionなら/trunk)
“master branch”が壊れて利用できない時間 - ツールのメンテナンスに使った時間
クラウド(AWS)、インフラ、監視、ツールの導入・設定に費やされた時間
継続的インテグレーションをはじめるために必要なコト
継続的インテグレーションをスタートするための一番良いタイミングは、プロジェクトの開始時である。継続的インテグレーションの導入は開発者の日々の開発方法をルールとプラクティスによって少しだけ変えるためである。開発者によっては手法の変更や変化に対して抵抗する場合がある。チームに大きな変化は受け入れられ難いが、小さな変化であれば可能である。可能な範囲で継続的インテグレーションを導入し、小さく初めることがとても重要である。
小規模な導入に必要な基本事項として
- チームが共有するソースコードのリポジトリを整備し
- 毎日の必ずコミットする
- できることから自動化(ソースコードのインスペクション、コンパイルやバイナリのパッケージ化を自動化など)
小さなスタートでは、自動テストやデプロイ自動化は実行しない方が良いと考える。テスト自動化や回帰テストは開発者がテストコードを作成する必要があるなど、要求するレベルが上がってしまい、経験不足な開発者やチームでは導入失敗することがあるためである。この段階では開発者が継続的インテグレーションの仕組みと使い方を身につけることが重要であり、変更の度にビルド結果、インスペクション結果を受け取ることで継続的インテグレーションのメリットを実感してもらえることから開始する。
参考
継続的インテグレーション入門 – 開発プロセスを自動化する47の作法
社内サーバにリモートリポジトリを作るのも一つですが、「開発にまつわる面倒事」をこの際全部、tracpath(トラックパス)に任せてみませんか?
バージョン管理サービス・プロジェクト管理サービスの「tracpath(トラックパス)」では、
ユーザー5名、リポジトリ数3つまで、無料で利用可能です。
さっそく実務でも使って見ましょう。
自らも開発を行う会社が作ったからこそ、開発チームの「作る情熱」を支える、やるべきことに集中出来るサービスになっています。
エンタープライズ利用が前提のASPサービスなので、セキュリティも強固です。