チケットのサイジングに対する継続的インテグレーションの影響
CI（継続的インテグレーション）の調査を行っていますが、CIがチケットのサイズ設定にもたらす変更に関する情報が見つかりません。
CIは、開発者は毎日（または1日に複数回）メインラインにマージする必要があると述べていますが、そうでない場合は、チケットのサイズを決定するときに、それらのチケットをさらに小さなチケットに分割する必要があります。完了するまでに1日以内ですか、それとも単体テストに合格したが完全なチケットではないコードのフラグメントを統合しているだけですか？
例： CIルールの下で開発者が（ユニットテストに合格した）コミットを統合する場合、私のチームは通常5営業日に相当する3のサイズになるチケットを持っていると言いますその日のメインラインへの移行（チケットはまだ完了していないことに注意してください）、またはCIのチケットが大きい場合は、チケットを小さいチケットに分割する必要があります。これらの新しい小さいチケットはそれぞれ、 1日以内に完了しますか？
cIルールの下では、開発者はその日に行ったコミット（単体テストに合格）をメインラインに統合します。
開発中の機能は、すべてのビルド/テストに合格することを継続的に確認できるように、分割して開発する必要があります。うまくいけば、CIプロセスは、マスターだけでなくブランチでも実行できるように設定されています。
急速に移動するリポジトリ（マスターへのマージが多い）で作業している場合、機能ブランチで作業しているときは、マスターをプルしてマージする必要があります。
次に、コミットを行うときは、現在マスターブランチであるものに非常に密接に取り組んでいます。これがCIをトリガーすると、CIのメリットが得られます。現在のコードに関する検証とフィードバックです。
ただし、コードをマスターにマージせずにブランチでCIを実行できない場合、またはCIをブランチで実行するようにトリガーできない場合は、チケットを分割する必要があります。
実用的には、これの多くはチームのワークフローに依存します。週に数回のマージしかない場合、チームが1日に20回マージする場合よりも、答えの重要性は低くなります。ブランチでCIを実行できない場合は、ブランチドリフト、特に「CIブランチドリフト」を回避する必要があります。
そのチケットはCIにとって大規模であり、次にチケットをより小さなチケットに分割する必要があり、それらの新しい小さなチケットのそれぞれを1日以内に実行する必要がありますか？
とにかくまともなアイデアですが、厳密には必須ではありません。
CIのポイントは、コードをコミット/マージするときに自動化されたプロセスを実行することです。これを行っておらず、5日以上待ってから行う場合は、実際にはCIを行っていません。それは問題ありません。そのプロセスがうまく機能するのであれば、CIのコアアイデアと実際には平行ではありません。アマゾンウェブサービスには本当に良い定義があります 彼らのサイトで （私の強調）：
継続的インテグレーションは、開発者がコードの変更を中央リポジトリに定期的にマージした後、自動ビルドとテストが実行されるDevOpsソフトウェア開発プラクティスです。継続的インテグレーションは、ほとんどの場合、ソフトウェアリリースプロセスのビルドまたは統合段階を指し、自動化コンポーネント（CIやビルドサービスなど）と文化的コンポーネント（頻繁に統合することを学ぶなど）の両方を伴います。継続的インテグレーションの主な目標は、バグをより迅速に見つけて対処し、ソフトウェアの品質を向上させ、新しいソフトウェアアップデートの検証とリリースにかかる時間を短縮することです。
これまで、チームの開発者は、延長された期間、単独で作業し、マージのみを試みる可能性がありました。作業が完了すると、マスターブランチに変更されます。このバッチ処理により、蓄積されたコード変更のマージが困難で時間がかかりました。これは、小さなバグが修正されずに長期間蓄積されると悪化します。これらの要因が組み合わさると、更新を顧客に迅速に提供することが困難になりました。
継続的インテグレーションでは、開発者はGitなどのバージョン管理システムを使用して共有リポジトリにコミットすることがよくあります。各コミットの前に、開発者は統合する前に、追加の検証レイヤーとしてコードに対してローカル単体テストを実行することを選択できます。継続的インテグレーションサービスは、共有リポジトリへのコミットを検出し、新しいコードの変更に対して単体テストを自動的に構築して実行し、機能エラーまたは統合エラーを即座に表面化します。
これを行わない場合、概して「CIを行わない」ことになりますが、これもチームのワークフローに依存します。ただし、バッチ機能の変更は、CIタイプのプロセスを解決するために開発されたほぼ正確な問題の状況であることを認識してください（Amazonの定義を参照）。
特にチケット管理のアプローチがうまく機能している場合は、継続的インテグレーションを行っているという理由だけで、チケットへのアプローチ方法を変更する必要はないと思います。
Grady Boochは、継続的インテグレーションを1日に複数回メインラインにマージすることとして定義しているかもしれませんが、継続的インテグレーションは、バージョン管理でのコードリポジトリの作成、ビルドの自動化、ビルドの統合など、一連の優れたプラクティスと考えることをお勧めします。バージョン管理により、すべてのコミットで合格/不合格のビルドが可能になり、自動テストが行われ、自動テストがビルドプロセスに統合され、ビルドに簡単にアクセスできるようになります。他に行うべきことは、コミット時のビルドプロセスを高速に保ちながら、有用なフィードバックを提供することだけです。システムによっては、すべてのコミットですべてのテストを実行できない場合があり、一部のテストをダウンまで延期する必要がある場合があります。 -時間（夜間、週末-システムを長期間実行でき、開発チームが結果を待っていない時間）。
定期的にフィードバックが必要であり、ビルドプロセスからフィードバックを受け取るため、定期的にビルドおよびテストされるブランチにコミットする必要があります。多くの場合、これは機能の終了やバグの修正という観点から語られます。ただし、一部の機能はより大きくなっています。コミットが問題を完全に解決する必要があるとは思いません。コミットは、バグ修正機能の実装をサポートするためにリファクタリングを実行している可能性があります。コミットでは、コードの変更に備えて、単体テスト（およびそれらをパスさせるためのコード-ビルドを中断しないでください）を追加することができます。コミットは、機能の一部であるがまだ呼び出されていない可能性のあるいくつかの新しいメソッドを記述している可能性があります（および パブリックメソッドの場合、それらが機能することを確認するための新しい単体テスト ）。または、コミットが機能そのものである可能性があります。
機能が完了する前にこれらの中間コミットをどのように処理するかはあなた次第です。私の現在のチームには経験則があります。ヘッドダウン時間が2時間以上かかるチケットで作業すると、サブタスクが作成されます。それはあなたのために働くかもしれないし、そうでないかもしれません。
人々が用語を定義する方法ではなく、チームに利益をもたらすグッドプラクティスに焦点を合わせます。 「継続的インテグレーション」に1日に複数回コミットすることを含む特定の定義があるからといって、CIの他の側面を使用してそのメリットを確認できないわけではありません。