走る前に歩く：CDにおけるCIを理解する

話題の 連続放出 （CD）今日では、それについて話すことさえ、ましてや書くことさえも時代遅れの考えのように思われるかもしれない。 継続的インテグレーション （CI）。しかし、CDの導入を検討している組織、あるいは導入の真っ最中（そして行き詰まっている）組織と多くの対話を重ねる中で、CD導入への組織の意欲を支える基盤となる側面において、埋めるべき大きな溝が存在することが明らかになってきました。CIは重要な基盤となる構成要素ですが、その原則は未だ十分に理解・実装されておらず、再検討する価値があります。

継続的…

統合 は、迅速かつ自動化されたフィードバックを引き出すプロセスです。 正しさ コードが変更されるたびに、アプリケーションを更新します。

出荷 以前のコンセプトを基に、高速で自動化されたフィードバックを提供することで、 正しさ (NAIST) と 生産準備 アプリケーションに変更があるたびに コード、インフラストラクチャ、または構成.

CDの前提は、ソフトウェアは常にデプロイ可能であるということです。ふむ。どこかで聞いたことがあるような気がします。最近、アジャイル宣言の背後にある原則をちょっと見た人はいますか？最初の原則はこうです。

「当社の最優先事項は、早期かつ迅速な対応を通じて顧客を満足させることです。 連続配送 – 貴重なソフトウェアです。」

CDは目新しい概念というより、長年の約束を実現するためのものであるように思われます。そして、この理想を実現するための重要な前提条件は次のとおりです。

• 継続的インテグレーション
• 包括的な構成管理
• マルチレベル自動テスト

残りの投稿では、CD の CI の側面についてもう少し詳しく説明します。

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

CIはソフトウェアビルドを実行するプロセスです。Deploy- チームメンバー間の継続的なコミュニケーションとフィードバックを基本原則として、最小限の手動介入で頻繁にテスト（BDT）サイクルを実施します。ソフトウェア開発に関する著名な著者であり講演者であるマーティン・ファウラーは、これを次のように説明しています。

「…チームメンバーが作業を頻繁に統合するソフトウェア開発手法。通常、各メンバーは少なくとも毎日統合を行い、1日に複数の統合を行うことになります。各統合は自動ビルド（テストを含む）によって検証され、統合エラーを可能な限り迅速に検出します。多くのチームが、このアプローチにより統合の問題が大幅に減少し、チームがより迅速にまとまりのあるソフトウェアを開発できることに気づいています。」

痛い場合は、痛みを前に出す

CIは、ソフトウェア統合エラーを迅速に検出するためのフレームワークを提供します。これにより、多くのソフトウェアチームを悩ませている、いわゆる「ビッグバン」統合とそれに伴うコードマージの煩わしさを軽減しながら、チームは統合ソフトウェアをより迅速に開発できるようになります。CIは、開発者が日々の開発活動の中で頻繁に作業の統合を行うことを奨励することで、統合の不確実性を排除することを目指しています。コードマージと競合解決という困難な作業そのものを排除するわけではありません。毎日、小規模で段階的なマージを実行することを義務付けることで、不定期なマージに伴う苦痛を大幅に軽減します。CIは、後々の深刻な苦痛を、今日の苦痛と交換するのです。

開発者の日々の業務はどのように変わりますか?

CIは考え方であり、プロセスは手動で実行することも可能ですが、多くのチームは規律を強制するためにツールを使用します。下の図は、CIサーバーなどのツールを用いてCIを実践する場合の典型的な統合サイクルを示しています。

• 一日は開発者がソース管理リポジトリから最新のコードベースを取得することから始まります。
• 次に、典型的な開発活動（できれば自動化されたユニットテストによってガイドされる）があります。
• 開発者はリポジトリにコードをコミットする準備ができており、チームに意図を伝える必要があるかもしれません。
• リポジトリからのコードでローカルの作業コピーを更新します（他の人がコードストリームを更新した可能性があるため）
• コードをマージし、ローカルで競合を解決する
• ローカルでビルドしてテストが合格することを確認する
• コードをリポジトリにコミットする
• CIサーバーはコードリポジトリの変更を「リッスン」します。変更があると、ビルドとテストのサイクルが自動的に開始され、その結果は自動的にチームメンバーに通知されます。ビルドが破損したり「レッド」になったりした場合（コンパイルまたはテストの失敗によるもの）、統合の失敗を示しているため、直ちに対処する必要があります。CI環境を「グリーン」にすることは、開発者/チームの最優先事項となるべきです。

どこから始めますか？

統合サイクルの説明から明らかなように、CI の導入には、CI を可能にして効果的にするために必要な特定のプラクティスが必須です。

単一ソースリポジトリ

CIサーバーはコードリポジトリへの変更を監視してBDTサイクルをトリガーするため、デプロイ可能なソフトウェア成果物の構築に必要なすべてのソースコードファイル、データベーススクリプト、依存ライブラリ、プロパティファイルは、何らかのソース管理システムでバージョン管理する必要があります。この制約は初歩的なものに思えるかもしれませんが、集中型のソース管理とバージョン管理が当然のものとなるほど成熟した段階にまだ達していない組織も存在します。

ビルド自動化

集中型のソース管理が導入されているにもかかわらず、多くの組織では、デプロイ可能なソフトウェア成果物の作成に依然として手作業のプロセスに依存しており、組織のサイロやチームメンバー間の調整が必要です。CIの前提は、人間の介入なしにビルドを開始することであるため、BDTサイクルを自動化するためには、ワンクリックビルド機能の構築が不可欠です。ビルド自動化の原則は、稼働中のシステムをゼロから立ち上げられることです。

テスト自動化

前提条件ではありませんが、 テスト自動化 ソフトウェアコンポーネントが統合されているだけでなく、正しく動作していることをチームに確実に伝える上で、テスト自動化は重要な役割を果たします。CIへの移行をテスト自動化が妨げにならないように注意が必要ですが、自動化のメリットを真に享受するためには、自動化テストの導入をすぐに開始するのが最善です。

「ベストプラクティス」にはどのようなものがありますか?

•  共通のコードストリームへの頻繁なコミット
• 「壊れた」ビルドへのコミットを禁止する
• CI上の「壊れた」ビルドはすぐに対処し、その解決を最優先にすべきである。
• 長時間実行されるビルドに対処しましょう。10～15分が理想的ですが、20～30分を超えると、意味のある頻繁な統合には限界があります。サイクルは短いほど良いでしょう。最も可能性の高い原因は、単体テストを装った統合テストです。必要に応じてビルドを段階的に実行してください。
• データベースを再構築する（ゼロから構築する）
• 本番環境のようなプラットフォームでビルド/デプロイ/テスト
• ターゲットビルドを上位レベルの環境に展開する機能を QA に提供する

どのような誤解があるのでしょうか?

CIはナイトリービルドと同じ

正しくはありません。ナイトリービルドは、外部での使用、例えばQA機能テストや製品レビューなどのためのソフトウェア成果物を生成します。XPはナイトリービルドの概念を極限まで推し進め、開発者がシステムと対話し、少なくとも当面は自分の役割を確実に果たしたことを確認する手段として、日中に頻繁にコード同期チェックポイントを設けることを提案しました。ナイトリービルドに価値がないと言っているわけではなく、実際、CIを用いて段階的にナイトリービルドを生成することも可能なのです。

私たちはアジャイルではないのでCIは行いません

「継続的インテグレーション」という用語はエクストリーム・プログラミング（XP）によって導入されましたが、より頻繁なインテグレーションという根底にある概念はXP以前から存在していました。実際、CIはXPで提唱されているプラ​​クティスの中で最も議論の少ないものの一つであり、その指針は組織がアジャイルを採用しているかどうかに関わらず適用されます。

頻出 Deployメント破壊的

CIの導入は、必ずしも要求の有無にかかわらず、すべての「グリーン」ビルドを上位レベルの環境に自動的にデプロイすることを意味するわけではありません。優れたCI実装では、QAチームや他のチームメンバーが必要に応じてCIサーバー上のターゲットビルドを他の環境にデプロイできる機能を提供する必要があります。

人々のための自動化 このシリーズでは、Paul Duvall が、一般的な CI のアンチパターンと誤解、およびその回避方法をいくつか紹介します。

結論

CIの最大のメリットは、リスクの軽減です。遅延や頻度の低い統合に伴う問題は、多くの場合、プロジェクトの後半、つまりリスクが高く、デリバリーへのプレッシャーが最も大きい時期に顕在化します。さらに、CIはビルド自動化、テスト自動化、そして最近では継続的デリバリー/継続的デプロイメントなど、様々なレベルでの自動化への道を開きます。これらはすべて、継続的な開発を促進することを目的としています。 より高品質なソフトウェア、 もっと早く。

参考情報

• http://martinfowler.com/articles/continuousIntegration.html
• http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html
• 継続的インテグレーション：ソフトウェア品質の向上とリスクの軽減 – Duvall, P & Matyas, S & Glover, A
• 継続的デリバリー：信頼性の高いソフトウェア Releaseビルド、テスト、そして Deployメントオートメーション – ハンブル、J＆ファーレイ、D