異なるインフラストラクチャの複雑さの展開と相まって、現代のソフトウェア開発のニーズは退屈なプロセスになるためのアプリケーションを作成することができます。アプリケーションは、スケールの成長を表示されたら、開発チームのメンバーは、より分散化となり、高速で生産し、それがより困難になるソフトウェアプロセスを配布し続けています。
これらの問題に対処するために、開発チームは、彼らがより速く新しい生産の展開を支援するために、彼らのビルド、テスト、およびリリースプロセスの自動化を行うために新たな戦略を模索し始めました。これは、原点連続配信や継続的インテグレーションの開発です。
この記事では、どのようなCI / CDとどのようにそれはすぐに完全にテストされ、信頼性の高いソフトウェアを開発し、展開するチームを助けることができますについて説明します。CI / CD及びその利点を見る前に、私たちはこれらの技術と議論事前に構築されたシステムのいくつかを練習してください。
自動ビルドプロセス
ソフトウェア開発プロセスでは、プロセスを構築する開発者が利用できる実行可能なソフトウェアにコードを生成しました。C言語やコンパイル言語に移動し、この相は、別々のバイナリソースコードコンパイラを実行することによって生成される必要があります。例えばPythonやPHPのようなインタープリタ型言語のために、そこにはコンパイル・ステップではないが、それでも簡単に配布するためにパッケージ化さ依存性を、結合、特定の期間内のコードを凍結する必要があります。これらのプロセスは、一般に「建物」や工作物の「解放」と呼ばれています。
開発者が手動で構築しますが、やってますが非常に多くの悪影響を持っています。まず、トランジションのビルドを作成するための積極的な開発からのコンテキストスイッチの導入は、開発者は、ビルドプロセスの作業に集中するより生産を停止しなければなりませんでした。第二に、ビルドプロセスの不整合が生じる可能性が自分の仕事の生産のすべての開発者、。
これらの懸念に対処するために、多くの開発チームは、自動ビルドパイプラインを装備します。これらのシステムは、ソースコードレポジトリを監視し、変更が検出されたときに自動的に事前設定ビルドプロセスを開始します。これで各と一貫性のあるビルドプロセスを確実にあまりにも多くの労働者が関与することなく、この構成。
これらの工程の多くは、ユーザーが、次のJavaエコシステムで、より人気のビルドツールのリストがある市場でのビルドツールを自動化するのに役立ちます。
アリ： Apache Antが2000年に設立され、オープンソースのJavaライブラリです。これは、元の建物のツール、Javaはまだ頻繁に使用される領域です。
Mavenは： ApacheのMavenは、主にJavaで記述されたプロジェクトのために、ビルド自動化ツールです。Apache Antを、Mavenのとは違った構成原理の上に規則に従って、値が外れ、合理的なデフォルトを構築するプロセスの態様のために設定することだけです。
Gradleの：提供される柔軟性を失うことなく、Mavenの、Antの同じ時間に結合することによって、現代の機能の利点を融合する2012バージョン1.0の発売、GradleのとMaven Antの試み。命令はGroovyの動的なと呼ばれる言語で書かれているビルドします。この地域ではあるが、これは比較的新しいツールですが、それは広く採用されています。
バージョン管理
最近のほとんどのソフトウェア開発は、共有コードベースで頻繁にコラボレーションを必要とします。バージョン管理システム（VCS）は、プロジェクトの履歴、並列処理の個別の機能を維持するだけでなく、競合する変更を解決するのに役立つために使用されます。VCSは、簡単にプロジェクトが変更を採用し、問題が発生した場合にロールバックすることができます。開発者は、ローカルコンピュータ上のプロジェクトを処理し、異なる開発ブランチを管理するためにVCSを使用することができます。
VCS内のすべての変更を記録提出すると呼ばれています。各ビュー提出歴史について、例えば、コードライブラリのカタログに対するすべての変更は、メタデータも含まれている提出したり、更新記述をマージします。
図1は、分散バージョン管理
バージョンコントロールしながら、単一のコードベースでは、さまざまな変更を管理するのに役立つことができる非常に貴重なツールです。しかし、多くの場合、彼らの開発課題を配布しました。合併後に開発することは、困難定期的に共有統合ブランチにマージが存在しない場合に、別のブランチライブラリ内のコードを変更することがあります。このような状況を回避するために、開発者は、継続的インテグレーションのプラクティスを採用し始めています。
継続的インテグレーション（CI）
継続的インテグレーション（CI）は、統合の作業は、開発者が共同開発を強化するために処理を分岐を共有することができますです。頻繁な統合は、アイソレーションを解決する競合をマージする可能性を低減するためには、各投稿のサイズを減らすことができます。
CIの実践を促進するためには、生態系が構築するための強力なツールとなっています。これらのシステムは、VCSのライブラリを統合する変更が検出されたときに、自動的にビルドスクリプトとテストスイートを実行します。統合テストは、チームができるだけ早くバグの互換性を見つけることができるように、さまざまなコンポーネントは、グループ内で互換性のある機能することを確認します。そのため、継続的な統合ビルドの生産は、十分にテストされ、完全に信頼性があります。
図連続統合プロセス2
持续交付和持续部署（CD）
持续交付和持续部署是在构建持续集成的基础之上的两种策略。持续交付是持续集成的扩展，它将构建从集成测试套件部署到预生产环境。这使得它可以直接在类生产环境中评估每个构建，因此开发人员可以在无需增加任何工作量的情况下，验证bug修复或者测试新特性。一旦部署到staging环境中，就可能需要进行额外的手动和自动测试。
持续部署则更进一步。一旦构建在staging环境中通过了自动测试，持续部署系统将会自动将它部署到生产服务器上。换言之，每个通过测试的构建都是实时的，可供用户及早反馈。这使得团队可以不断发布新特性和修复bug，并以其测试流程提供的保证为后盾。
图3 CI / CD流程路线图
CI/CD的优势
持续集成、交付和部署对软件开发过程有显著的改进。下文将简单介绍一些CI/CD的主要优势：
快速反馈回路
对于一个快速的开发周期，快速反馈回路显得尤为重要。为了能够实时接收反馈，软件必须迅速触达终端用户。而CI / CD可以通过简化更新生产部署来提供实现此目标的平台。通过要求每个更改都经过严格的测试，CI可以帮助降低每个构建的相关风险并因此使得团队可以便捷地向用户发布有价值的特性。
增加可见度
CI/CD通常是指将IT流程的各个步骤按序列组成一条流水线，且该流水线对整个IT团队（包括开发、测试、运维等团队）均可见。因此，每个团队成员可以跟踪系统中的构建状态并且可以确定任何导致测试失败的构建。团队成员通过深入了解代码库的当前状态，可以更轻松地规划最佳行动方案。这样的可见度为这一问题提供了一个明确的答案——“我提交的更改是否破坏了构建？”
简化故障排除
尽管CI的目标是集成并测试每个发生在代码库中的更改，但是更安全的方式是每次提交都是小型的并尽早将它们合并到共享代码存储库中。如此，当找到bug时，确定和问题相关的更改会更加容易。毕竟，根据问题的严重程度，团队可以选择回滚或编写并提交修复，从而减少生产中解决问题的时间。
软件质量更高
自动化构建和部署流程不仅缩短了开发周期，而且帮助团队开发出品质更好的软件。因为每个更改都会经过充分的测试并且至少会部署在一个预生产环境中，因此团队可以毫无顾虑地将更改部署到生产中。不过，只有当代码库的所有级别，从单元测试到更复杂的系统测试，都有良好的测试覆盖率时，才能实现这一点。
集成问题更少
因为自动化测试套件在每次提交时自动生成的构建上运行，所以可以尽早检测并修复集成问题。这使开发人员能够及早了解当前正在进行的工作是否可能影响其代码。它会在一开始就测试由不同贡献者编写的代码是否兼容，而不是在之后可能出现其他问题的时候才开始测试。
有更多的时间专注于开发
CI/CD系统依赖自动化来生产构建并且通过流水线来迁移新的更改。由于不需要手动干预，因此构建和测试不再占用开发团队大块的时间。进而开发人员可以心无旁骛地对代码库进行有效的更改，因为如果构建过程中出现任何问题，自动化系统会通知他们。
既然我们已经了解了使用CI/CD的一些优势，那么接下来，我们将讨论一些指导原则来帮助您成功实现这些流程。
对CI / CD流水线负责
开发者直到更改被部署到预生产环境中，才无需对其提交的代码负责。这意味着开发者必须确保他们的代码集成正确并且随时可以部署。如果提交的更改违反了这些要求，则开发人员有责任快速提交修复以避免影响其他人的工作。构建失败应该暂停流水线并阻止不参与修复故障的提交，这使得快速解决构建问题变得至关重要。
确保部署一致
部署过程不需要手动操作，反而流水线需要自动部署流程以确保一致性和可重复性。这减少了将破坏性构建推向生产的可能性，并有助于避免出现一些难以重现的、未经测试的配置。
将代码库提交到版本控制
各変更は、制御が非常に重要であるバージョンに提出されます。この変更は、すべての提出を検討し、チームは単に提出問題を復元することができるようにするチームを助けるだろう。また、設定、スクリプティング、データベースおよび文書の完全性を維持することができます。多くの人が同じコードベースを使用する場合は特に、何のバージョン管理がない場合は、紛失したり、不適切な構成やコードの変更自分の治療にするのは非常に簡単になります。
小さな、増分変化によって提出
開発者は、心に留めておく必要があります。変更は小さくなければなりません。変化の大きなバッチの導入を待っていることは、テストのフィードバックが遅れますので、問題の根本原因を特定することはより困難になります。
良いテストカバレッジ
CI / CDの目的は、手動テストを削減することであるので、全体のコードベースは、予想通り、ソフトウェアが実行されていることを保証するために、優れた自動テストカバレッジを持っている必要があります。また、パイプラインの影響を避けるために、定期的に廃止されたまたは冗長検査をクリーンアップする必要があります。
同様の試験の異なる種類のテストスイートの割合とすべき「試験ピラミッド」モデル。彼らは基本的な機能を持っているだけでなく、すぐに実行できるため、ほとんどのユニットテストは、テストする必要があります。また、コンポーネントが正常に一緒に実行できるようにする統合テストの数が少ないがあります。最後に、それはすべてのプロジェクトには、建物の挙動の要件を満たしていることを確認するためにテストを終了するには、テスト期間、UI、システムおよびエンドの最後にリターンを少量含まれている必要があります。あなたは、テストスイートは、コードベースをカバーしてどのくらいかを決定するためにこのようなJaCoCoなどのツールを使用することができます。
図4テストピラミッド
エピローグ
大幅に開発サイクルを短縮し、開発チームの生産性を向上させるCI / CD表示されます。そのアジャイル、安定性と信頼性の特性は、ますます企業やニーズによって支持されています。この記事では、まず事前に構築されたシステムで、自動ビルド、バージョン管理、およびJava環境でビルドツールのいくつかを与えるの技術と実践を紹介し、その後、継続的インテグレーション（CI）を導入し、継続的な配信と連続展開（CD）の概念と、その利点、および最終的なように良いテストカバレッジを確保する、一貫性のある展開を確保し、などいくつかのベストプラクティスを、提供します。私たちは、あなたがCI / CDの性質や機能を明確に役立つことを期待して、だけでなく、初心者のCI / CDが紙エントリによって行うことができることを願っています。