ビルド自動化対デプロイ自動化対継続的統合

もっと効率的になりたいし、opsツールを効率的に使いたい。

これを念頭に置いて、私は継続的インテグレーションについてもっと学びたかったのですが、それに関して多くの異なることがあるようです。

私は実際に私の仕事（IntelliJ、WebStorm ...）でJetbrainsスーツを使っているので、それらを使い続けたいと思っていました。

私の問題は、以下の違いがわからないことです。

• ビルディングオートメーション（TeamCityはこの種のソフトウェアです）：リモートVCSリポジトリを使用してアプリケーションをビルドできることは知っていますが、それは素晴らしいことですが、その主な目的は何ですか？これを行う際にどのような情報が重要ですか？実際、ソフトウェアがローカルでビルドされているかどうか、チームメートも既に知っています。それでは、自動化を展開せずにそれを使用する目的は何ですか？

• 自動化の展開（TeamCityは簡単に実行できないようです）

• 継続的インテグレーション（上記の2つの組み合わせのようです）
• 継続的デリバリ（これは正確に何ですか？なぜ継続的インテグレーションと異なるのですか？）

これをもう少し理解してもらえますか？

ウィキペディアは、これらの用語のほとんどのかなり良い要約を提供します。ここに私の見解があります：

• ビルド自動化とは、コンパイラーを手動で呼び出す代わりに、ソフトウェアのビルド方法を自動化することです。これは、MakeやAntなどのツールを介して実現されます。

• 展開の自動化とは、ビルドされたソフトウェアを取得し、テストシステムまたは運用システムに展開またはインストールすることです。

• 継続的インテグレーションとは、開発者がコードをチェックインするときに自動化プロセスでソフトウェアを継続的にビルドし、ユニットテストを実行してコードが引き続き機能することを確認することです。たとえば、15〜30分ごとにサーバーが起動し、VCSで新しいチェックインをスキャンし、変更があった場合はプロジェクトを更新してビルドします。コンパイル手順の実行に加えて、これは自動化された単体テストとコード品質チェックを実行する絶好の機会です。

• 継続的デリバリは、ソフトウェアビルドもテストシステムに展開され、必要に応じてテストを実行し、レポートを生成する、以前のすべての概念の組み合わせです。

少なくとも、ビルドの自動化、つまり何らかのビルドスクリプトが必要です。これにより、1つのボタンをクリックするか、1つのコマンドを発行してプロジェクトをビルドできます。これの利点は、ステップを手動で実行することによるエラーを減らすことです。複雑なビルド環境には、コードの生成（構成からDAOを考える、JAXBなどのインターフェイスコード）、コードのコンパイル、パッケージ化、メタデータのカスタマイズなどが含まれる場合があります。ビルドスクリプト、およびツールを使用して実行しますか？エラーを減らし、一貫性を提供します。

次はCIです。これは本当に便利ですが、必須ではありません。ビルドの問題を早期に特定するのに役立ちます。複数の開発者が1日を通してコードをチェックインし、おそらく自分のワークスペースを常に同期していない場合、変更が相互に干渉するリスクがあります。バージョン管理の競合ではなく、静的なコードエラーを具体的に参照しています。CIビルドサーバーは、このリスクを軽減します。

最後に、展開手順があります。ここでのアイデアは、時間を節約し、ソフトウェアを手動で展開することによるエラーを減らすことです。ビルドの自動化と同様に、ソフトウェアの展開を台無しにする方法は100あります。私は、明日現場に来る顧客のために機能するシステムを必要とする多くの場面で、手動での展開の問題を修正するために個人的にオフィスに遅く滞在しました。複数のシステムの紹介に多くのリスクを自動化：代わりに、一つのシステムは、おそらくクラッシュしたり奇妙なエラーを有するので、私たちが今持っている複数の失敗する可能性のあるシステム。ただし、そのリスクは、誰かがチェックリストのステップを逃したり、間違ったコマンドを発行して展開を台無しにしたりするよりもはるかに低くなります。運がよければ、DBバックアップを復元して最初からやり直すことができます。運が悪ければ、エラーが発生してシステムが正しく機能しなくなる可能性があります。ソフトウェアの欠陥ですか？技術者は構成を正しく設定しませんでしたか？これには、診断に時間がかかりますが、プロセスを自動化する場合は、必要のない時間と費やす必要のない時間がかかります。

• 継続的インテグレーションは、すべての開発者の変更を1日に数回、共有メインラインにマージするプラクティスです。現在、このプラクティスは非常に遍在しているため、それほど重要ではないように思えるかもしれませんが、従来のチームは数週間または数か月間も単独でソフトウェアを操作していました。結果は、個別の作業ストリームが一緒にマージされたときの「統合地獄」でした。通常、継続的インテグレーションは共有メインラインの自動ビルドで使用され、問題を早期に発見しますが、devopsよりも頻繁なコミットと開発者のワークフローを重視します。

• 自動ビルドは、ビルドをローカルでパスする可能性があるが、ビルドサーバーで失敗する問題を拾うのに役立ちます（たとえば、ファイルのチェックインを忘れた、ビルドサーバーの依存関係が一致しないなど）。ビルドサーバーにこれらの問題を検出させることは、チームメイトが行う前に修正​​できることを意味します。

• 継続的デリバリには、ソフトウェアの継続的な展開、実行、テストが含まれます。自動ビルドにより、ソフトウェアが実際にビルドされる（および単体テストに合格する）ことは保証されますが、展開スクリプトが引き続き機能することや、ソフトウェアが実際にエンドツーエンドで実行されることを意味するものではありません。継続的デリバリの目標は、メインラインが本番環境への展開に適した状態にとどまることを保証する一連のチェックを行うことです。

• 連続展開は次の論理的なステップです。連続配信パイプラインを正常に通過するすべてのコミットを自動的に展開します。このプラクティスにはいくつかの利点がありますが、私にとっての主なアイデアは、小規模で頻繁なコミットのリスクが少ないことです。

詳細については、この本を読むことをお勧めします。

• 継続的デリバリー：ビルド、テスト、展開の自動化による信頼性の高いソフトウェアリリース

多くのビルドツールのようなTeamcityは、多くの異なるタスクを実行できる中央アプリです。これには、CIビルド、フルリリースビルドなどのビルドの実行が含まれ、展開を実行できます。teamcityを使用してantまたはnantを呼び出してソリューションファイルでmsbuildを実行している場合、展開を実行するnantスクリプトを呼び出すこともできます。少しスクリプティングが必要かもしれませんが、難しくありません。

完全なCI、データベースCIにはteamcityとbambooを使用し、INTegration環境に展開します。その後、teamcityを使用して完全なリリースビルドを作成し、db移行スクリプトを自動的に作成します。これらは、nantスクリプトを呼び出すteamcityジョブを介してSVNにチェックインされます。デプロイについては、ご想像のとおり、teamcityを使用してnantを呼び出してデプロイタスクを実行します。これは、teamcityエージェントがteamcityサーバーと通信し、エージェントがDMZの場所にあるサーバーの1つに存在し、ファイアウォールなどを越えてコードを移動するのに役立つため、うまく機能します。 。