このページでは,継続的インテグレーションについて知っておきたいあらゆるポイントを解说します。継続的インテグレーション,継続的デプロイメント,継続的デリバリーの微妙な违いに触れつつ,ソフトウェアの构筑とテストを自动化する方法に沿ってユースケースとベストプラクティスを绍介していきます。


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

継続的インテグレーション(CI)は,デプロイするコードの品质を确保しながら,开発スピードを向上させるソフトウェア开発戦略です。开発者は継続的にコードを少しずつ(少なくとも1日1回,可能なら1日に数回)コミットし,そのコードが共有リポジトリにマージされる前にビルドとテストが自动的に実行されます。

継続的インテグレーション:概要

  • 开発者は1日1回またはそれ以上の频度で,共有メインラインコードリポジトリにコミットを行う。
  • コミットのたびに,コードベースの自动ビルドと自动テストがトリガーされる。
  • ビルドやテストが失败しても,数分以内にすばやく修复できる。

継続的インテグレーションは,アジャイル手法と密接に关系しています。チームメンバーは小さく分割された一连の「ストーリー」に取り组み,ソフトウェアの変更コードは,共有ソフトウェアリポジトリに1日に何度も少しずつマージされます。

継続的インテグレーションは,多くのソフトウェアプロジェクトに适用できます。たとえば,CircleCIでは的Webサイトの更新に継続的インテグレーションを采用しています。

  1. 开発者(またはコンテンツ発行者)がコードの新しいブランチをGitHub的に作成し,ページのHTMLを更新して,変更をコミットします。

  2. そのブランチの変更がすべて完了したら,开発者がGitHub的にプルリクエストを作成します。

  3. GitHub上とCircleCIを连携させているため,コードを基にCircleCIでビルドプロセスが実行され,その后に自动テストスクリプトが実行されます。

  4. CircleCIでエラーが発生した场合(ビルドステータスがレッド),开発者にその旨がメールで通知されます。

  5. エラーが発生しなければ,ビルドが成功して(ビルドステータスがグリーン),コードがステージングサーバーにプッシュされたことが通知されます。これで,开発者は网络ページのプレビューを确认できるようになります。

  6. 検证が完了したら,开発者は新しいブランチのコードを本番环境にマージできます。


継続的インテグレーション,継続的デリバリー,継続的デプロイメントの违い


継続的インテグレーション
新しいコミットごとに自动でアプリケーションのビルドとテストを行います。

継続的デリバリー
アプリケーションをいつでもデプロイできる状态にします。実际にアプリケーションをデプロイするには,手动の操作が必要です。

継続的デプロイメント
ビルド,テスト,デプロイメントを自动で行います。すべてのテストに合格すると,新规のコミットごとに新しいコードが开発パイプライン全体を通过して本番环境にプッシュされます。手动の操作は介在しません。

継続的デリバリーと継続的デプロイメントの违いを示した図。主な违いは,継続的デリバリーではデプロイするときに手动の操作が必要であり,継続的デプロイメントは完全に自动化されている点です。

关连记事
継続的デリバリー- Martin Fowler的氏
継続的デリバリー与継続的デプロイメント- 杰斯谦卑氏
継続的デプロイメント- 蒂莫西菲茨氏
継続的デリバリー- 维基百科
継続的インテグレーションとは- 列夫Lazinskiy
そもそも継続的デプロイメントって何?- 劳拉Franzese
DevOps的の歴史まとめ,パート3:自动テストと継続的インテグレーション- 阿列克夏尔马氏
的DevOpsの歴史まとめ,パート4:継続的デリバリーと継続的デプロイメント- 阿列克夏尔马氏


継続的インテグレーション(CI)と継続的デプロイメント(CD)


継続的インテグレーションは,ソフトウェアのビルドとテストを自动化する手法です。継続的デプロイメントは,この自动化の延长线上にあり,コードのコミットが毎回テストスイートに合格しなければ,ソフトウェアはデプロイされません。特に大きな成果を收めている开発チームでは,高い频度でソフトウェアをデプロイしています。

ソフトウェア开発プロセスは,主に3つの作业で构成されます。

  1. コードの作成:ソフトウェア开発チームの创造性が最も発挥される场面です。ユーザーストーリーを洗练されたコードに落とし込みます。

  2. ソフトウェアとしての「新しいコードのオーケストレーション」:継続的インテグレーションの核心はここにあります。开発者がコードをコミットすると,継続的インテグレーションのビルドサーバーがビルド,テスト,デプロイメントのプロセスを自动的に実行します。

  3. 配信:新しいソフトウェアを本番环境にリリースする最终ステップです。この段阶では,本番环境でのソフトウェアの监视と管理を行うツールが使用されます。

コードの作成で最も重要なツールは,コードを保持しておくために使用されるリポジトリです.CircleCIはGitHub的や到位桶と连携しています.CircleCIのサーバーソリューションなら,GitHub的企业とも连携が可能です。金宝博娱乐官网网址

CircleCIは,オーケストレーションの段阶で机能し,コードを有效なソフトウェアに変换するという,最も负荷の大きい作业を担います。ユーザーは,YAMLファイルを介してコードを处理する方法を构成します.YAMLファイルはコードで设定でき,ほぼあらゆることを际限なく构成できるため,开発チームは思いのままにビルドとテストを実行できます。

配信では,テストと承认が完了したコードが本番环境に展开されます。これには,运用サーバーのセットアップ,构成,管理が含まれます。継続的インテグレーションのメリットを最大限に引き出すには,継続的デプロイメントが欠かせません。


CI / CDを导入する方法


アプリケーション开発のできるだけ早い段阶で継続的インテグレーション(CI)パイプラインを整备することが重要です.CIパイプラインにテストを追加すれば,テストに合格しないコードは主にマージされなくなるため,开発者は安心してイノベーションと开発に打ち込むことができます。また,継続的デプロイメントのワークフローをCIパイプラインに组み込むことで,デプロイメントの自动化が可能になります.CircleCIを利用すれば,ソフトウェアのビルド,テスト,デプロイメントを自动化でき,エンジニアはユーザーにとって特に重要な机能の构筑に集中できます。

导入のステップ

  1. 全员の认识を统一する。新しいCI / CDツールを导入する目的について意识の统一を図ります。

  2. 必ず小さなところからスタートする。一夜にして理想的な的DevOpsチームを作り上げることはできません。まずは1つのチームでプロセスを変更し,その変更が组织内で有效かどうかを确认しましょう。改善が见られたら,少しずつ进めていきます。

  3. 自分たちに适しているかどうか见极める。组织によっては的DevOpsが适していない可能性があることも理解しておきましょう。実际,DevOps的を导入しなくても长年成功を收めている企业も存在し,そうした企业にとっては社内文化や制品に対するニーズなどの面から的DevOpsが最适なソリューションとは言えないのです。たとえば,制品戦略において机密性が特に重要になる企业では,段阶的に配信を行ってフィードバックを集めるのは现実的ではありません。大规模なリリースを行うまで,制品についてのすべての详细を秘匿しておく必要があるからです。そのような环境で的DevOpsの文化を筑くことは非常に难しいでしょう。

  4. 常に测定する。改善计画を実行に移す前に,现状を正确に测定しておきます(开発サイクルには○时间かかっているなど)。サイト信頼性の担当エンジニアを开発チームに招集するよりも,まず指标を测定しましょう。少し时间がたてば,取り组みの效果を确认できます。一例を挙げると,アジャイル手法による変革が盛んに行われていたころ,多くの企业がスタンドアップミーティングを采用しましたが,その必要性をよく理解していないケースや,実施效果を测定していないケースが目立ちました。これでは,スタンドアップミーティングによって时间が节约されたどころか,无駄になっていたかもしれません。

  5. なんでも自动化しようとしない。少なくとも一度にすべてを自动化するのはやめておきましょう.DevOpsに关して,インフラストラクチャのプロビジョニングと构成管理をすべて自动化しなければならないとお考えの方もいらっしゃるようですが,これは误解です(こうしたインフラストラクチャは「コードとしてのインフラストラクチャ」と呼ばれます)。中には手动のほうがうまくいくこともあり,自动化がすべての最适解となるわけではありません。场合によっては,手动の方法から始めて,実际に何が最良の自动化ソリューションとなるのかを见极めなければならないこともあります。

継続的インテグレーションは,新しいツールを导入して终わりではありません。その本质は,开発チームの仕事の进め方を変え,新たなマインドセットを形成することです。そして,组织の文化を変えるのは简単な道のりではありません。継続的インテグレーションを始めるにあたっては,小さなところからスタートしていくのが最善の方法となります。

今后予定している小规模なプロジェクトで概念実证を行い,次のような基盘を整えましょう。

  • 厳格なテスト手法,理想としては自动テストの実装
  • テストから本番环境まで,一贯性のあるソフトウェア环境
  • 継続的インテグレーションの実践に关するトレーニング
  • 重要な测定指标に关するレポート

定期的に小さな増分ごとにコミットするようになると,バグへの対応がとてもスムーズになることが実感できるはずです。すばやくバグを解决できれば,机能の配信もスピードアップできます。その势いに乘って,継続的インテグレーションを组织全体へと拡大していきましょう。


継続的インテグレーションと継続的デプロイメント(CI / CD)のベストなツール


DevOps的とは,开発チームと运用チームの连携关系に特化した手法です。基本的には,文化的な観点から,インフラストラクチャに开発手法を适用し,开発サイクルに运用手法を适用します。具体的な内容を说明すると,インフラストラクチャをコードとして管理することや,再利用可能なコンポーネントを构筑してイミュータブルなインフラストラクチャを作成すること(いつでも分解·破弃でき,バージョン管理や変更履歴の记录も容易です)が挙げられます。また,すべてのプロダクトコントリビューターたちが「制品が世の中でどう役に立っているのか」「ユーザーはどのように操作しているのか」など,自身が进めている作业の最终的な结果にもっと关心を持つようになります。本気で品质を意识すれば,ビジネス価値とユーザビリティの両方を意识することになります。これこそ,DevOps的导入による真の成果です。

こうした手法を采用するには,広范囲から支持を取り付けなくてはならず,さまざまなスキルや専门知识を持つ人々の助けが必要になるため,ソフトウェア开発チームにとっては特に难しいでしょう。それでも実现するには,部门を超えた1つのチームとして,配虑あるコミュニケーションを心がける必要があります。たとえば,エンジニアがデータベースの问题についてビジネスサイドのだれかと话すときには,単に作业に关连するデータを提示するだけでなく,必要な背景情报も伝え,问题意识を持つべきポイントやその理由について强调することが大切です。

では以上を踏まえて,新しいツールを导入する必要があるか考えてみてください。必要だと言い切れない方もいらっしゃるのではないでしょうか。ツールは,手っ取り早い手段のように思えることもありますが,どんな状况にも使える万能の武器というわけではありません。新しい的DevOpsツールを导入する前に,こうしたポイントを踏まえておくと,成功の确率が高まるでしょう。チームにとって一番适したツールが,ベストなCI / CDツールなのです。

关连记事
DevOps的への移行:本当に必要なツールとは- 六月荣格
新しいツールをチームに导入する方法(そしてその过程でつぶされないようにする方法))- 艾玛·韦布
最新情报:CircleCIは月间3000万件以上のビルドをどう处理しているか- 罗布朱伯


クラウドホスト型とオンプレミスの継続的インテグレーション


CircleCIはクラウドマネージドサービス(SaaS)的として提供されています。また,お客様のプライベートインフラストラクチャのファイアウォール内でCircleCIを実行していただくことも可能です。

クラウド
お客様の継続的インテグレーションインスタンスのセットアップ,セキュリティ対策,メンテナンスはCircleCIが行います。リリースされた机能にすぐにアクセスでき,自动的にアップグレードも行われるため,メンテナンスの负担が軽减されます.GitHubまたは到位桶のアカウント认证から,登录,ビルドの成功まで,ほんの数分で完了できます。

サーバー
お客様のプライベートサーバーにCircleCIをインストールし,お客様のチームでセットアップやセキュリティ対策の管理を行っていただけます。システム管理者にすべての権限が付与されるため,完全なカスタマイズが可能です。更新のタイミングは,メンテナンスのスケジュールに合わせて决定できます。


継続的インテグレーションのメリット


継続的インテグレーションの基本的な考えは非常にシンプルで,频繁に,少なくとも毎日,コードをコミットして统合します。ソフトウェア开発プロセスでは,このような小さな変更が,ときに大きな成果をもたらします。

この开発戦略には次のようなメリットが期待できます。

  • チームの生产性向上と效率化
  • 市场投入までの时间短缩
  • プロダクトマーケットフィットの検证
  • より高品质で安定した制品のリリース
  • 顾客満足度の向上
  • 开発意欲の维持とコード配信の継続

ワークフローの简単な変更からこのようなメリットが得られる理由
コミットの频度を高めれば,マージの竞合を早期に発见して解决することや,完全に回避することも可能になります。つまり,1000行のコードを书いてからエラーを见つけ出そうとするのではなく,100行书いただけでコミットしていくのです。そうすれば,コード内のバグ探しが,数时间ではなく数分で済みます。これがチームの生产性向上につながり,作业したコードをより迅速にリリースできるようになります。

新机能を迅速にリリースできるということは,市场投入までの时间が短缩されるということです。これにより,次の2つの重要な点で竞争力を高められます。

  1. 顧客が新機能をすぐに利用できるようになり,顧客満足度の向上につながります。

  2. 企业としては,新机能の投资回收期间が短くなります。次のマイルストーンまでリリースを待つのではなく,新机能の准备が整ったらすぐに市场に投入して価値を実现できます。


オープンソースプロジェクトのCI / CD


CircleCIは,LINUXのオープンソースプロジェクト用に毎月40万クレジットを免费プランのお客様に提供しています。ご利用条件は,リポジトリを公开することだけです。免费プランを使用してMACOSでビルドを行っている组织にも,毎月25000クレジットが无料で提供され,MACOSオープンソースプロジェクトのビルドに利用できます。ご希望の方は,billing@www.drag240sx.comまでお问い合わせください。


継続的インテグレーションのベストプラクティス


継続的インテグレーションを実践している开発者は,早い段阶から频繁にコミットしています。そうすることで,コードを本番环境にデプロイする前に,竞合を検出できます。また,より小规模にコミットすることで,问题が発生した场合のトラブルシューティングが容易になります。ただし,ソフトウェアを毎日,またはそれ以上の频度でコミットすることは,継続的インテグレーションには必要ですが,それだけでは十分ではありません。

継続的インテグレーションを成功させるには,次のことを行う必要があります。

  • テストを开発プロセスの一部として不可欠な要素とする(テストは,コードの作成と同时に记述するべきです)
  • テスト环境が本番环境を反映したものとなるよう彻底する
  • ペアプログラミングなど,コーディングのベストプラクティスを采用する
  • デプロイメントのワークフローを自动化する

厳格なテスト文化を育むことは,企業が継続的インテグレーションを成功させるうえで必要となる最も重要な要素です。自信を持って新しいコードをメインラインに統合するためには,コードが正常であるという確信が必要となります。エンジニアは,各機能の開発中にテストを記述するべきです。CircleCIでは、新しいコードがコミットされるたびにテストが実行され、ビルドがグリーン (成功した) か、レッド (失敗して問題の修正が必要) かが開発者に通知されます。テストを実行しないのであれば、ビルドが成功しても意味がありません。自動化されたテストを活用するのは必須ではないものの、理想的と言えます。Rainforest QA などの QA サービスを継続的インテグレーションのプロセスに組み込むのもよいでしょう。

厳格なテストの文化を支えていくには,テスト环境が本番环境を反映していることが重要です。そうでなければ,テストしているものが本番环境で动作するという保证はありません。つまり,テスト环境のデータベース,网络サーバー构成,アーティファクトなどは本番环境のものと同じである必要があります。

ソフトウェア开発のもう1つのベストプラクティスは,ペアでコーディングすることです。复雑な机能については,1行のコードを记述する前に,アーキテクチャのアプローチについてペアで议论を行います。コードを本番环境にマージする前には,常に别の开発者がコードレビューを行います。これにより,コーディングのベストプラクティスが适用されていること,コードが既存のコードまたは别の开発者が作业しているコードと竞合していないこと,新机能が拡张可能であることを确认できます。

さらに,ソフトウェア开発パイプライン全体を高速かつ效率的にするためには,デプロイメントワークフローも自动化する必要があります。そうすることで,完成したコードをより迅速に本番环境に展开できます。ソフトウェアを短时间で开発できても,顾客の手元に届けなれば意味がありません。


継続的インテグレーションを追迹するための重要な指标


継続的インテグレーションは,どのソフトウェア开発チームにとっても価値のある目标です。しかし,目标を达成したかどうかを确认するにはどうすればよいでしょうか。そこで出番となるのが,重要业绩评価指标(KPI)です。ソフトウェア开発ライフサイクルの改善を図るなら,それを构成するプロセスについて测定する必要があります。そうすることで,プロセスの変更が效果を生んでいるかかどうかがわかります。

以下に,ソフトウェア开発について测定する4つのKPIを绍介します。

  • リードタイム:最初のトリガーからワークフローの完了までにかかる実行時間の長さです。実行結果のシグナルをどれだけ速く取得できるかを示します。リードタイムを短くするには,極限まで自動化されたソフトウェア開発パイプラインが必要です。だからこそ,ビルドやテストを自動化するために継続的インテグレーション(CI)を行うのです。CIによるパイプラインの自動化によって,数週間から数か月かかっていたデプロイメントのタイムラインが,数分とまではいかなくても,数時間に短縮されます。
  • デプロイメントの频度:ワークフローを开始する频度は,どれくらいの数の个别の作业が开発パイプラインを通过しているかを示す指标となります。完全に自动化されたソフトウェア开発パイプラインでは,コードベースへの复雑な更新も自动的にデプロイできます。ホットフィックスであっても,他の更新と同様に厳格なテストを経て速やかに配信できます。
  • 平均复旧时间(MTTR):复旧までにかかる时间は,有用な情报をどのくらい迅速に入手できるかによって変わります。失败したというステータス情报をすばやく取得できれば,エラーの状态から最短时间で正常に戻すことができます.CI / CDを导入することは,高速なフィードバックループを実现するカギとなるので,开発者に迅速かつ确実にシグナルを伝える最善の方法と言えます.CI / CDをしっかりと実践するには,テストスイートのログやカバレッジレポートなどのリアルタイムのアーティファクトを作成することも求められます。それによって,开発者は本番环境と同等の环境でトラブルシューティングを行えます。
  • 変更の失败率:优れたパフォーマンスを夸るチームが不良コードをデフォルトブランチにプッシュすることは稀です。しかし,そうしたチームが欠陥のあるコードを决して记述しないというわけではありません。テストとセキュリティチェックを别のブランチで実行し,すべてが成功した场合にのみマージが许可されるようにすることをお勧めします。コードをデフォルトブランチにマージする前に,そのコードが正常に动作することをきちんと确认するべきです。

定期的にレポートを作成するとよいでしょう。日次レポートの作成を自动化しておくと,エラーの発生をすぐに検知できます。また,周次レポートを分析することで,CIプロセスを掘り下げて振り返り,改善点を见つけることができます。

今すぐダウンロード:「データで见るCI:3000万のワークフローから明らかになった的DevOpsの実际」


テストをCI / CDパイプラインに组み込む


テストにはいくつかの种类があります。

単体/コンポーネントテスト
可能な限り最小のコンポーネント,ユニット,机能を対象とします。依存关系やモックをあまり必要としないため,実行コストが最も低い最速のテストです。パイプラインの早い段阶で実行して终わらせる必要があります。

结合テスト
前のステージから移行された各ユニットが他のコンポーネント,ユニット,机能と连携してどの程度正常に动作するかを确认します。広义では,サービス(APIなど)が正常に相互连携できるかどうかのテストを指します。

UIレイヤーテスト
自动化されたブラウザーベースのテストで,基本的なUIフローを确认します。セットアップにコストがかかり,実行に时间がかかるため,パイプラインの后半で実行します。

では,これらのテストがソフトウェア开発パイプラインにどう组み込まれるのかについて说明します。テストごとに个别の役割があり,実行する场所が决まっています。