Continous Integration（CI）とは何ですか？[閉まっている]

継続的インテグレーションの概念、どのように機能するのかを理解しやすい方法で説明してくれる人がいますか？そして、企業がコード配信ワークフローにCIを採用する必要があるのはなぜですか？私は開発者であり、私の会社（主にビルド​​チーム）はTeam Cityを使用しています。開発者として、私は常にコードをチェックアウトし、更新してSVNにコミットしますが、TeamCityやCI全般について気にする必要はありませんでした。それでは、CIの有用性を理解したいと思いますか？CIはアジャイル手法の一部ですか？

簡単に言えば、継続的な統合とは、作業を保存し、ドキュメント管理システム（ケースではSVN）にプッシュし、すべてのテストを自動的に実行し（ユニット、統合、機能などのテスト）、アプリケーションをコンパイルして準備することを意味します配信用（つまり、ISOイメージが作成されます）。継続的統合は、継続的デリバリーとは異なります。配達はまだ別の瞬間に行われます。CIは、必要な場合にのみ製品を配信できるようにします。

何か問題が発生するたびに、チームは通知を受け取ります。通常、その時点ですべての作業が停止され、すべての努力は製品が安定した方法であることを確認することに集中します。システムがグリーンでない間は、リポジトリでプッシュとコミットは発生しません。

CIは、製品が常に安定した状態にあり、潜在的にいつでも配送できることを保証します。安定しているとは、機能が完全であることを意味しないことに注意してください。機能が半分実装されている場合もありますが、システムは安定しています。

CIは通常、アジャイル手法に関連付けられていますが、CIの正確な歴史は個人的に知りません。

継続的統合とは、実際に実行されテスト可能な製品にコードを統合することであり、開発ライフサイクルの後期の別のアクティビティとしてではなく、常に発生します。

それには、アプリケーションのビルドプロセスを完全に自動化すること、および自動化されたテストスイート、およびコードの現在の状態をビルドしてテストスイートを実行するサーバーが必要です。これは毎日、または各コードのチェックイン後にも発生します。

利点は、コンパイルエラー（たとえば、開発者がすべての変更のチェックインに失敗したか、ビルドシステムに存在しないコンポーネントを使用したため）またはテストケースの失敗を引き起こすコードの変更に関するフィードバックがあることです。これにより、そのようなエラーの修正がはるかに簡単になります。どの変更がエラーを引き起こしたかを知っており、担当者はまだ何をしたかの新鮮な記憶を持っているからです。

CIがなければ、これらのエラーはすべて統合段階で同時に発生し、修正が非常に困難になります。

開発には、チェックアウト、コーディング、コンパイル、チェック、呪い、変更、コンパイル、応援、コミットなど、特定のスタイルがあります。作業コードをコミットするのは、おそらく仕事の終わりや機能が完了したときなど、粒度の低い方法でもです。APIライブラリをインポートするたびに依存関係を検証します。

他のユーザーと一緒にコーディングを開始し、相互依存関係がある場合、継続的インテグレーションを採用することは理にかなっています。あなたのコードに依存する人々への変更の影響を知ることができず、インポートを更新する必要があるたびにシグナルを受け取らないからです。

したがって、どちらかが変更を加える場合、両方のプロジェクトを一緒にビルドおよびテストする必要があります。つまり、互いのAPIに対して実行し、新しいライブラリを使用してビルドおよびテストします。

なぜ連続するのですか？いずれかのコードベースに変更があるたびにクリーンビルドをテストするシステムに統合の調整を委任するほうが、人間のためにすべてを整理するよりも簡単だからです。システムは拡張可能です。

継続的インテグレーションには2つの側面があります。

1. 開発者が進行中の作業を他の開発者の安定したコードと継続的に統合できるようにする開発ソース管理戦略。
2. ソース管理へのコミットによってトリガーされるソースコードの自動ビルドとテスト

ポイント1は重要です。開発者が実際に実行するマージを頻繁に行う動きであり、本質的に小規模であるため、マージが成功する可能性が高くなります。

ポイント2は、ポイント1を安全に発生させるために必要なツールとフレームワークであり、既存のコードを壊すことで失敗したマージを迅速に特定します。

それはどれほど便利ですか？

信じられないほど。プロジェクトに取り組んでいる開発者は、チームの他のメンバーからの並行作業を心配することなく、ほとんどの時間を自分がしていることに集中することができます。現在の作業が完了したら、変更をチームの他のメンバーに公開し、今後数時間ですべての変更を現在の作業にマージします。

それなしでは、開発者はビッグバンマージを行っています。通常、作業に数日かかり、それをチームの他のメンバーが行ったすべての変更と一度にマージする必要があります。マージが著しく悪くなった場合、他の開発者はおそらく他の作業に移り、マージの混乱を解くのに役立つ細かい詳細を忘れ始めているでしょう。さらに悪いことに、継続的なビルドとテストを行わないと、コードがコンパイルされる限り、コードにマージバグが現れる可能性があり、テスト（または顧客）がそれらを見つけるまで検出されません。

CIは次の場合に役立ちます。

• コードのコンパイル
• テストの実際のセット
• ソースコード（コードカバレッジ、コード標準の違反など）に基づくレポート
• コードが正常にコンパイルされた後、定期的に実行するルーチン

リストを継続できます。