継続的インテグレーション（CI）とは何ですか。
継続的インテグレーションの概念を理解しやすい方法で説明してくれる人がいますか？また、企業がコード配信ワークフローでCIを採用する必要があるのはなぜですか？私は開発者であり、私の会社（主にビルドチーム）はTeam Cityを使用しています。開発者として、私は常にコードをチェックアウト、更新、SVNにコミットしますが、TeamCityやCI全般について悩む必要はありませんでした。では、CIの有用性とは何かを理解したいと思いますか？ CIはアジャイル手法の一部ですか？
一言で言えば、継続的な統合とは、作業を保存し、それをドキュメント管理システム（ケースではSVN）にプッシュし、すべてのテスト（ユニット、統合、機能などのテスト）が自動的に実行され、アプリケーションがコンパイルおよび準備されることを意味します。配信用（つまり、ISOイメージが作成されます）。継続的インテグレーションは、継続的デリバリーと同じではありません。配達はまだ別の瞬間に行われます。 CIは製品を保証します可能性があります必要に応じて配信されます。
問題が発生すると、チームに通知が送られます。通常、その時点ですべての作業が停止し、製品が安定した状態にあることを確認することにすべての努力が集中します。システムがグリーンでない間は、リポジトリでプッシュとコミットは行われません。
CIは、製品が常に安定した状態であり、いつでも配信できることを保証します。安定とは、機能が完全であることを意味しないことに注意してください。半分実装された機能もありますが、システムは安定している可能性があります。
CIは通常、アジャイル手法に関連していますが、私はCIの正確な履歴を個人的に知りません。
継続的インテグレーションとは、実際に実行してテストできる製品にコードを統合することです常時、（以前のように）開発ライフサイクルの後半の個別のアクティビティではありません。
これには、アプリケーションのビルドプロセスが完全に自動化されていること、および自動テストスイートと、コードの現在の状態を構築してテストスイートを実行するサーバーが必要です。これは毎日、または各コードのチェックイン後にも発生します。
利点は、コンパイルエラーの原因となるコード変更（開発者がすべての変更のチェックインに失敗した、またはビルドシステムに存在しないコンポーネントを使用したなど）またはテストケースの失敗に関するフィードバックがすぐに得られることです。これにより、そのようなエラーの原因となった変更を確認でき、責任者はまだそれらのエラーについて新しい記憶を持っているため、そのようなエラーを修正するのがはるかに簡単になります。
CIがないと、統合段階でこれらすべてのエラーが同時に発生し、修正が非常に困難になります。
あなたは開発中に特定のスタイルを持っている可能性があります：チェックアウト、コード、コンパイル、チェック、呪い、変更、コンパイル、応援、コミット。作業中のコードをコミットするだけで、おそらく、1日の仕事の終わりや機能が完了したときなど、きめ細かい方法でコミットすることもできます。 APIライブラリをインポートするたびに、依存関係を確認します。
他のユーザーと一緒にコーディングを開始するとき、および相互依存関係があるときは、継続的インテグレーションを採用することは理にかなっています。単に、コードに依存する人々への変更の影響を知ることができず、インポートを更新する必要があるたびにシグナルを受信しないからです。
したがって、どちらかが変更を加える場合、両方のプロジェクトを一緒にビルドしてテストする必要があります。つまり、互いのAPIに対して実行し、新しいライブラリを使用してビルドしてテストする必要があります。このようなテスト、コード、および他の誰かのテストは、統合テストと呼ばれます。
なぜ継続的ですか？いずれかのコードベースに変更があるたびにクリーンビルドをテストするシステムに統合の調整を委任する方が、人間のためにすべてを整理するよりも簡単だからです。システムは拡張可能です。
継続的な統合には2つの側面があります。
- 開発者が進行中の作業を他の開発者の安定したコードと継続的に統合できるようにする開発ソース管理戦略。
- ソース管理へのコミットによってトリガーされるソースコードの自動構築とテスト
ポイント1は重要です。開発者が実際に実行するマージを頻繁に行うための動きであり、マージが成功する可能性を高くするのは性質が小さいためです。
ポイント2は、ポイント1を安全に発生させるために必要なツールとフレームワークであり、既存のコードを壊すことで失敗したマージをすばやく識別します。
それはどれくらい便利ですか？
信じられないほど。プロジェクトに取り組んでいる開発者は、ほとんどの時間を自分の作業に集中することができ、チームの他のメンバーからの並行作業について心配する必要はありません。現在の作業が完了したら、変更をチームの他のメンバーに公開し、次の数時間ですべての変更を現在の作業にマージします。
それがなければ、開発者はビッグバンのマージを行っています。通常、作業には数日かかり、チームの他のメンバーが行ったすべての変更を一度にマージする必要があります。マージが著しく悪くなると、他の開発者はおそらく他の作業に移り、マージの混乱を取り除くのに役立つ詳細を忘れ始めます。さらに悪いことに、継続的なビルドとテストを行わないと、コードがコンパイルされる限り、マージバグがコードに現れる可能性があり、テスト（または顧客）がバグを見つけるまでピックアップされません。
CIは、次の場合に役立ちます。
- コードのコンパイル
- テストの実際のセット
- あなたのソースコードに基づいたレポート（コードカバレッジ、コード標準の暴力など）
- コードが正常にコンパイルされた後、定期的に行うルーチン
リストを続けることができます。