継続的インテグレーション

menu icon

継続的インテグレーション

このガイドでは、継続的インテグレーションについてご説明します。これは、各開発者が少なくとも1日に1回、新規コードをメインブランチのコードと統合する、ソフトウェア開発とDevOpsのプラクティスです。

継続的インテグレーションとは

継続的インテグレーションとは、開発サイクル全体を通じて、開発者が作成した新規コードをより頻繁に統合し、少なくとも1日に1回はコード・ベースに追加する、ソフトウェア開発プロセスです。 ビルドの各反復に対して自動化されたテストが行われます。これは統合の問題をより早い段階で特定するためであり、修正が容易になるほか、リリースのための最終マージ段階で問題が生じるのを回避する上でも役立ちます。 総じて、継続的インテグレーションはビルド・プロセスを合理化し、高品質のソフトウェアと、より予測可能なデリバリー・スケジュールを生み出すのに役立ちます。

継続的インテグレーション(CI)、継続的デリバリー(CD)、継続的デプロイメントの比較

継続的インテグレーションでは、各開発者は少なくとも1日に1回(または、可能であれば1日に複数回)、自らの作業をソースコードのメインブランチに統合します。 もう1つのDevOpsプラクティスである継続的デリバリーは、更新、バグ修正、さらには新機能を含む、コード・ベースに対する検証済みの変更を、できる限り迅速かつ安全にユーザーに提供することに重点を置いています。 継続的デプロイメントは、自動化されたテストを使用してコード・ベースの変更を検証することによってプロセスをさらに合理化し、より迅速な更新を可能にします。

継続的デリバリーは継続的インテグレーションの拡張と位置付けられ、選択されたインフラストラクチャー環境へのアプリケーションのデリバリーを自動化します。 これにより、開発環境、テスト環境、実稼働環境など異なる環境へのコード変更のプッシュが確実に自動化されるようになります。

メリット

以下は、継続的インテグレーションがもたらす最も顕著なメリットの一部を示したものです。

  • 継続的かつ可視化された進展により、フィードバックが改善される
  • 早期の、改善されたエラー検出とメトリックにより、エラーの早期解決(場合によってはチェックインから数分以内)が可能となる
  • チーム・コラボレーションが改善され、すべてのチーム・メンバーがコードの変更、システムの統合、ソフトウェアの他の部分との競合の迅速な特定を行うことができる
  • システム統合が改善され、これによりソフトウェア開発ライフサイクルの終了段階での予期せぬ問題が減少する
  • マージとテストにおける並列変更が減少する
  • システム・テストにおけるエラー数が減少する
  • システムが頻繁に更新されてテスト対象となる

CI、アジャイル、DevOps

アジャイル

アジャイルは、ソフトウェア開発チームがどのようにチーム編成を行い、要件変更に適応し、ソフトウェアをリリースするかを改善する、ソフトウェア開発プラクティスです。 継続的インテグレーション(IBM外部へのリンク)アジャイル開発(PDF、153 KB)は、多くの機能(テストの自動化など)が共通しているため、継続的インテグレーションとアジャイルについて同時に取り上げるのは有用と言えます。 アジャイルは、開発を小規模の作業グループまたはスプリントに編成します。 DevOpsにおいて適用した場合、これらの複合的なプラクティスは、ソフトウェアの品質とプロジェクトの柔軟性を確保するのに役立ちます。

継続的インテグレーションでは、頻繁に(多くの場合、1日に何度も)作業を統合する必要があります。 統合エラーを可能な限り早期に検出する自動ビルドによって、統合を検証します。 ビルドには、検証の一環として実行テストを組み込む必要があります。 高速テストを、自動化されたテスト環境でのランタイム・テストに拡張することで、自然に継続的デリバリーへとつながっていきます。

アジャイル(IBM外部へのリンク)も反復型であり、変更に適応することで、時間の経過に合わせてソリューションを拡張、発展させることができます。 継続的インテグレーションのコンテキストにおいて、アジャイル・ソフトウェア開発とは、継続的に統合を進める中で、機能の価値をどのように優先順位付けするかに基づいて、ソフトウェア開発の反復を実施することを指します。

DevOps

DevOpsのフレームワークにおいて、継続的インテグレーションはソフトウェア開発プロセスの初期段階に位置します。少なくとも1日に1回はコードのチェックインを行うことで、ローカル・コピーが、コード・ビルドのメインブランチからあまりにかけ離れたものになるのを防ぎます。 これにより、ビルドが「破損」して問題解決のためにチームが長時間拘束されることとなるような、マージでの致命的な競合を回避できます。

継続的インテグレーションは、継続的デリバリーのテスト、デプロイメント、リリースの各段階の、前提条件としての役割を果たします。 開発チーム全体で、不適切なコードが作成されたかどうかをチェックインの数分以内に把握できます。これは、継続的インテグレーション・サービスによって、コード変更が自動的にビルドされ、エラーがないかがテストされるためです。

オープンソースの継続的インテグレーション・ツール

以下に紹介するのは、最も一般的な継続的インテグレーション・ツールの一部です。

  • Jenkins: 広く使用されているオープンソースの継続的インテグレーション・ツールであるJenkinsにより、開発者はコードをソース・リポジトリーにコミットした後すぐに、そのコードを自動的にビルド、統合、テストできます。そのため、開発者にとって、バグを早期に把握し、ソフトウェアをより迅速にデプロイすることが容易になります。 JenkinsではDockerプラグインを使用できます。
  • Buildbot: Buildbotは、ソフトウェア開発サイクルのあらゆる側面を自動化できます。 ジョブ・スケジューリング・システムとして、ジョブをキューに入れて実行し、結果を報告します。
  • Go: Goが傑出しているのはパイプラインの概念であり、これが複雑なビルド・ワークフローのモデリングを容易にします。
  • IBM UrbanCode Build
  • Travis CI: 最も古く、最も信頼されているホスト型ソリューションの1つであり、エンタープライズ向けのオンプレミス・バージョンでも利用可能です。
  • GitLab CI: オープンソースのRailsプロジェクトの不可欠な部分であるGitLab CIは、無料のホスト型サービスです。アクセス管理、課題追跡、コード・レビューなどの機能を備えた、詳細なGitリポジトリー管理を提供します。

オープンソース・ツールを活用して継続的インテグレーションを実施すると、以下のような多くのメリットがあります。

  • プロジェクトをサポート可能な数百ものプラグイン
  • Python、Java、JavaScriptなど、オープンソース言語を広くサポート
  • コストがかからないため、学生やスタートアップ企業、副業で働く開発者が、予算に優しい強力なツールとして利用可能
  • カスタマイズ可能であるため、開発者はCIツールの基盤を活用しながら、さらにニーズに合わせた構築が可能
  • ツールを変更・再配布する機能

お客様のソフトウェア開発ワークフローのために検討すべき、オープンソースの継続的インテグレーション・ツールには、Jenkins、Go、Buildbot、Travis CIなどがあり、これらについては次のセクションで読むことができます。

ユースケース

以下の架空のユースケースは、2人のソフトウェア開発者が継続的インテグレーションを使用して、DevOpsプロセスをどのように改善できるかを示したものです。

この2人の開発者は、どの機能がどのように作動するかについて、互いに意思疎通を図る必要があります。 この少人数チームは定期的な更新を行う必要があり、コード全体を統合・テストできなくてはなりません。 コード・チェックインのスケジューリングとテストには、多くの開発時間を要します。 継続的インテグレーションのための自動システムが必要となります。

チェックインとテストをいつ実施するかについての交渉は、開発者の多くの時間を消費することになります。

円滑な交渉のためには、チームで以下について合意する必要があります。

  1. コード統合のテストをいつ開始するのか
  2. 統合が成功したことをどのようにテストするのか
  3. 結果をチームにどのように伝達するのか

継続的インテグレーションのプラットフォームでは、これらの質問に対する既定の答えがあります。さらに、そのほとんどで、構成とセットアップが可能となっています。

通常、JenkinsのようなCIプラットフォームは、チェックイン時に統合テストを開始します。 新規コードがチェックインされると、CIシステムは一連のテスト(単体テストと回帰テストを含むこともある)を実行し、コードが正常に統合されたかどうかを判別します。

または、コンパイル済み言語を使用している場合は、コードが正常にコンパイルされるかどうかのデフォルトのテストが行われます。 正常にコンパイルできない場合は、新規コードが原因でビルドは破損したということです。 PythonまたはJavaScriptのような言語の場合は、独自の統合テストを作成する必要があります。

いずれにしても、ほとんどのCIシステムは統合の試行回数、成功率、その他のメトリックをログに記録します。

サーバー

継続的インテグレーション・サーバーは、お客様のあらゆる継続的インテグレーション・オペレーションを集中管理し、プロジェクトを構築するための信頼性の高い安定したプラットフォームを提供するソフトウェア・ツールです。 CIサーバーを構成、調整することで、複数の異なるプラットフォーム用にさまざまなプロジェクトを構築できます。 継続的インテグレーション・サーバーは、複雑なワークフローを簡単にモデル化および可視化し(それによって継続的デリバリーを可能にする)、継続的デリバリーのパイプラインを構築するための直感的なインターフェースを提供します。 継続的インテグレーション・サーバーは、以下を行うための機能を提供します。

  • ビルド、テスト、リリースを単一の場所で自動的に実行する
  • 任意のバージョンをいつでもデプロイする
  • 正しい手順に沿った構成を維持する
  • プラグインをサポートして機能性を拡張する
  • プロジェクトのリポジトリーをモニターする
  • 変更をプルし、正常にコミットするために定義したタスクを実行する
  • ビルドの詳細を含むフィードバックを、関連するプロジェクト・メンバーに送信する

テストの重要性

継続的テストは、継続的インテグレーションのビルドとパッケージ(インストール可能エンティティーまたはパッケージ・エンティティーとも呼ばれる)を生成する際に開始されます。 そしてパッケージ・エンティティーが実働状態に入ると終了します。 エンドツーエンドのすべてのステップにテスト・スイートは関与します。

テスト・ステージが1つしかない最低限の場合でも、継続的インテグレーションの30%にテストが含まれます。 実際には、継続的インテグレーション活動の50%から70%はテストで構成されています。 以前は、手動でテストを完了する必要がありました。 今では自動化されたテストを使用でき、これは継続的インテグレーションを成功させる上での鍵となります。

継続的インテグレーションのためのテスト自動化の一環として、テスト駆動開発はコードを繰り返し作成し、一度に1つのユースケースをテストすることでテスト・カバレッジを確保し、コード品質を高め、継続的デリバリーのための基礎を築きます。 自動化されたテストにより、アプリケーションのすべての機能領域で開発されたテストのうち、1つ以上で新規コードが不合格となったかどうかが分かります。 ベスト・プラクティスでは、開発者はローカル環境ですべてまたは一部のテストを実行する必要があります。これにより、新たなコード変更がテストに合格した場合にのみ、開発者によってソースコードがバージョン管理にコミットされるようになります。 経験上、効果的な回帰テストはその後の不測の事態を回避するのに役立ちます。

継続的インテグレーション・パイプライン

継続的インテグレーション・パイプラインは、プロジェクトのパイプラインの段階(ビルド、テスト、デプロイメントなど)を反復可能な方法で、最小限の人間の介入で自動化します。 自動化された継続的インテグレーション・パイプラインは、管理、チェックポイント、スピードをもたらすことにより、アプリケーションの開発、テスト、デプロイメントを簡素化する上で、不可欠となっています。

ベスト・プラクティス

継続的インテグレーション・プロセスは、DevOpsの重要なコンポーネントであり、ソフトウェアのコーディング、テスト、デプロイ、サポートを行うために、共有リポジトリーによって開発チームと運用チームを統合するのを支援します。 以下は、お客様の成功に役立つCIのベスト・プラクティスを示したものです。

  • 単一のソースコード・リポジトリーの維持:ソース制御管理を使用して、製品をビルドするためのすべてのファイルを追跡・管理します。 この統合されたコード・ベースにより、配布と可視性の実現が容易になります。
  • ビルドの自動化:これには、ビルド成果物を生成するコンパイル、リンク、他のプロセスが含まれます。 セルフテストも自動化する必要があります。
  • 日次でのメインライン・コミットの実施:少なくとも毎日1回は、変更をメイン開発ストリームにコミットするよう開発者に強制します。 各開発者は、それぞれの作業用コピーがメイン開発ストリームと整合していることを確認する必要があります。
  • 実稼働環境の複製でのテスト:テスト環境を、最終的な実稼働環境と可能な限り同じようにします。
  • デプロイメントの自動化:ビルドとテストを実行するため、複数の環境(開発、統合、実動)を実装します。

継続的インテグレーションとIBM Cloud®

IBMのアプローチは、プロジェクトを定義して自動化し、セキュリティーを構成するのにテンプレートを使用するというものです。 ライブラリーに対する変更が行われると、従属アプリケーションが再ビルドされて、接続、リンク、あるいは再結合されます。 アプリケーションの依存関係を理解することは、 アプリケーションのモダナイズに役立ちます。

組織がこうしたデジタル・トランスフォーメーションを加速するにつれ、ビジネスとITの業務で自動化ニーズが拡大します。 さらなる自動化への移行は、小規模で測定可能なプロジェクトの成功から開始する必要があり、その後、他のプロセスや組織の他の部分へ拡大や最適化を行うことができます。

IBMと協業することで、事前構築されたワークフローを含む、AIを活用した自動化機能を利用できるようになります。これにより、あらゆるプロセスをよりインテリジェントなものにすることで、イノベーションを加速させます。

詳細情報はこちら:

- IBM® UrbanCode® Buildの助けを借りながら、スケーリングや構成を含むソフトウェア・ビルドの管理を開始しましょう。

- このHFS調査レポートにある自動化成功のための5つの「必須事項」(IBM外部へのリンク)をお読みください。

今すぐIBM Cloudアカウントを使用して開始しましょう。