ビルドオートメーションvsデプロイオートメーションvs継続的インテグレーション
より効率的になり、運用ツールを効率的に使用したい。
これを念頭に置いて、継続的インテグレーションについてもっと学びたかったのですが、それについてはさまざまなことがあるようです。
私は実際に自分の仕事（IntelliJ、WebStorm ...）でJetbrainsスーツを使用しているので、それらを引き続き使用したいと思いました。TeamCityは、継続的な統合のための多くのプラグインを備えた素晴らしいツールのように思えました。
私の問題は、次の違いが何であるかわからないことです。
ビルディングオートメーション（TeamCityはこの種のソフトウェアです）：リモートのVCSリポジトリを使用してアプリケーションを構築できることは知っています。それはすばらしいことですが、その主な目的は何ですか。これを行う際、どのような情報が重要ですか？実際、私は自分のソフトウェアがローカルでビルドされるかどうか、そして私のチームメイトもすでに知っています。では、自動化を導入せずにそれを使用する目的は何ですか？
自動化の展開（TeamCityはそれを簡単に実行していないようです）
- 継続的インテグレーション（上記の2つの組み合わせのようです）
- 継続的デリバリー（これは正確には何ですか？継続的インテグレーションとはなぜ異なるのですか？）
これについてもう少し理解していただけますか？
ウィキペディアはこれらの用語のほとんどのかなり良い要約を提供します。これが私の見解です。
ビルドオートメーション は、手動でコンパイラを呼び出すのではなく、ソフトウェアのビルド方法を自動化します。これは、たとえば、 Make または Ant 。
デプロイメントの自動化とは、ビルドしたソフトウェアを取得して、テストシステムまたは本番システムにデプロイまたはインストールすることです。
継続的インテグレーション は、開発者がコードをチェックインし、ユニットテストを実行してコードを確認するときに、自動プロセスでソフトウェアをビルドする継続的ことを意味しますまだ動作します。たとえば、15〜30分ごとにサーバーが起動し、 [〜＃〜] vcs [〜＃〜] をスキャンして新しいチェックインを探し、変更があった場合はプロジェクトを更新してビルドします。これは、コンパイル手順の実行に加えて、自動化された単体テストと コード品質チェック を実行する絶好の機会でもあります。
継続的デリバリー は、ソフトウェアビルドがテストシステムにも展開され、オプションでテストが実行され、レポートが生成される、以前のすべての概念の組み合わせです。
少なくとも、あなたはビルドの自動化（つまり、ある種のビルドスクリプト）を必要としています。これにより、1つのボタンをクリックするか、1つのコマンドを発行してプロジェクトをビルドできます。これの利点は、手動で実行するステップからのエラーを減らすことです。複雑なビルド環境には、コードの生成（- DAOs 構成から考える [〜＃〜] jaxb [〜＃〜] などのインターフェイスコード）、コードのコンパイル、パッケージ化が含まれる場合があります、メタデータのカスタマイズなど。チェックリストが必要なことはたくさんあります。チェックリストをビルドスクリプトにして、ツールを使用して実行してみませんか？エラーを減らし、一貫性を提供します。
次はCIです。これは本当にで十分ですが、必須ではありません。ビルドの問題を早期に特定するのに役立ちます。複数の開発者が1日中コードをチェックインしていて、おそらく自分のワークスペースを常に同期していない場合、それらの変更が互いに干渉するリスクがあります。私は、バージョン管理の競合ではなく、静的なコードエラーに特に言及しています。 CIビルドサーバーは、このリスクを軽減します。
最後に、展開手順があります。ここでのアイデアは、時間を節約し、ソフトウェアを手動で展開することによるエラーを減らすことです。ビルドの自動化と同様に、ソフトウェアのデプロイメントを台無しにする方法は100通りあります。私は個人的にオフィスに遅く滞在し、明日オンサイトに来る顧客のために機能するシステムが必要な多くの場合に手動の展開の問題を修正しました。複数のシステムを自動化するとリスクが高まります。1つのシステムがクラッシュしたり、奇妙なエラーが発生したりする代わりに、multipleシステムで問題が発生する可能性があります。ただし、そのリスクは、誰かがチェックリストの手順を見逃したり、間違ったコマンドを発行してデプロイメントをめちゃくちゃにするよりもはるかに低くなります。運が良ければ、DBバックアップを復元して最初からやり直すことができます。運が悪ければ、エラーによってシステムが正しく機能しない可能性があります。ソフトウェアの欠陥ですか？技術者は構成を正しく設定しませんでしたか？これには、診断に時間がかかりますが、プロセスを自動化する場合は、時間を費やす必要はありません。
継続的インテグレーション は、すべての開発者の変更を1日に数回共有メインラインにマージする習慣です。このプラクティスは今や広く普及しているため、それほど重要ではないように思われるかもしれませんが、従来はチームがソフトウェアを個別に数週間または数か月間作業していました。その結果、別々の作業ストリームがマージされたときに「統合地獄」が生まれました。継続的インテグレーションは通常、問題を早期に発見するために共有メインラインの自動ビルドで使用されますが、DevOpsよりも頻繁なコミットと開発者のワークフローが重要です。
自動ビルドは、ビルドがローカルでパスする可能性があるが、ビルドサーバーで失敗する問題をピックアップするのに役立ちます（たとえば、ファイルをチェックインするのを忘れた、ビルドサーバーの依存関係が一致しない）。ビルドサーバーにこれらの問題を検出させることは、チームメイトが行う前に問題を修正できることを意味します。
継続的デリバリーには、ソフトウェアの継続的な展開、実行、およびテストが含まれます。自動ビルドは、ソフトウェアが実際にビルドされる（そしてユニットテストがパスする）ことを保証しますが、展開スクリプトが引き続き機能することや、ソフトウェアが実際にエンドツーエンドで実行されることを意味するものではありません。継続的デリバリーの目標は、メインラインが本番環境への展開に適した状態に留まることを保証する一連のチェックを行うことです。
継続的デプロイは次の論理的なステップです。継続的デリバリーパイプラインを正常に通過するすべてのコミットを自動的にデプロイします。この方法にはいくつかの利点がありますが、私にとってここでの主な考え方は、小さな頻繁なコミットはリスクが少ないということです。
詳細については、この本を読むことをお勧めします。