6

次の原則に従う新しいワークフローを設計しようとしています。

  • 自動検証 (CI) に合格したコミットのみをメインラインにマージする必要があります (具体的には、マージされた状態は、統合ブランチを可能な限り初期状態に保つために CI に合格する必要があります)。
  • 人間によるコード レビューに合格したコミットのみをメインラインにマージする必要があります
  • 自動検証に合格したコミットのみを別の人間がレビューする必要があります (ビルドしてテストに合格しない場合でも、他の人の時間を無駄にしないでください)。
  • 機能ブランチは CI でカバーする必要があります (独立して、統合ブランチにマージされません - これは開発中の開発者にとって役立ちます)

git、Stash、TeamCity を使用しています。これは私が思いついたものですが、どれも完璧ではありません。提案の微調整や新しいアイデアを探しています。

ワークフロー 1

  • 開発者は機能/VHPC-1 で開発します (機能ブランチは TeamCity の通常の CI でカバーされます)
  • 機能が完了すると、開発者はプル リクエストを作成します: feature/VHPC-1 --> mainline

  • プル リクエストが別の開発者によって承認されると、Stash によって自動的にメインラインにマージされます (メインラインは TeamCity の通常の CI によってカバーされます)。

  • 問題: マージの競合がある場合、Stash はマージを実行しませんが、メインラインへのマージが完了するまで、マージされた状態はまったくテストされません。メインラインが壊れるかどうかは、壊れるまでわかりません。

ワークフロー 2

  • 開発者は機能/VHPC-1 で開発します (機能ブランチは TeamCity の通常の CI でカバーされます)
  • 開発者は、feature/VHPC-1 から feature/VHPC-1/review にプッシュします (統合ブランチをリベースしてから CI (マージされた状態のテスト) を実行します)
  • 機能が完了すると、開発者はプル リクエストを作成します: feature/VHPC-1/review --> mainline

  • プル リクエストが別の開発者によって承認されると、Stash によって自動的にメインラインにマージされます (メインラインは TeamCity の通常の CI によってカバーされます)。

  • 問題: マージされた状態がテストされてから統合が行われるまでの時間 (20 分～1 日?) により、統合ブランチが変更され、マージされた状態が機能しなくなる可能性があります。統合分岐が壊れる可能性。

  • 問題: ブランチの数が 2 倍になるということは、複雑さと作業が増えることを意味します。

ワークフロー 3

  • 開発者は機能/VHPC-1 で開発します (機能ブランチは TeamCity の通常の CI でカバーされます)
  • 機能が完成したら、開発者はプル リクエストを作成します: feature/VHPC-1 --> feature/VHPC-1/review

  • 別の開発者がプル リクエストを承認してマージすると、feature/VHPC-1/review が自動的にビルドされ、マージされた状態でテストされ、成功するとメインラインに自動マージされます

  • 問題: ブランチの数が 2 倍になるということは、複雑さと作業が増えることを意味します。

  • 問題: コミットは常にメインラインに統合する必要があり、ブランチをリリースするためにチェリー ピックのみを選択する必要があります。

ワークフロー 4

  • 開発者は機能/VHPC-1 で開発します (機能ブランチは TeamCity の通常の CI でカバーされます)
  • 機能が完了すると、開発者はプル リクエストを作成します: feature/VHPC-1 --> メインラインの TeamCity は自動的にレビュアーを追加し、マージされた状態でプル リクエストのビルドとテストを試みます (Stash の文書化されていない refs/pull を使用) -リクエスト/マージ)

  • 自動検証に合格すると、TeamCity はプル リクエストを承認します。その後、人間がそれをレビュー、承認し、メインラインにマージします。

  • 問題: TeamCity は、統合ブランチが変更されると変更される refs/pull-requests/merge を監視します。つまり、統合ブランチが 1 つの新しい変更を取得すると、開いているすべてのプル リクエストでビルドがトリガーされます。

4

2 に答える 2

3

元 Stash 開発者です。いくつかの一般的な考え。

Stash チーム (および私が協力して観察したほとんどのチーム) は、「楽観的な」ブランチ ビルドを行っています。つまり、ソース ブランチが正常にマージされれば、おそらくメインライン ビルドが壊れないという前提/希望の下でソース ブランチをビルドするということです。そして、私の経験では、これはほとんど常に当てはまります。

いくつかのオプション:

  1. 何もしない - メインラインが最終的に壊れた場合は、すぐに修正してください
  2. 赤いビルドを生成するマージ コミットを自動で元に戻すだけです (最初は手動で行うこともできます) 。
  3. PR マージは早送りのみである必要があり、開発者はマージバックする前にメインラインから手動でリベース/マージする必要があります
  4. カスタム ゲートキーパー プラグイン/ボタンを Stash に追加して、「統合後にグリーン ビルドでマージする」ようにします。これにより、実際のマージを行う前に、最初に 1 回限りのマージ ビルドが行われます。

一般的に、Stash の非表示の 'merge' ref からビルドすると、プル リクエストが開いている時間の長さによっては、おそらくビルドが多すぎることに同意します (ご指摘のとおり)。

それが役立つかどうかわかりませんか？

于 2014-07-15T10:57:42.643 に答える
0

ワークフロー 4 をお勧めしますが、わずかな変更があります

  • チェックインがあるときはいつでも、すべてのフィーチャー ブランチで CI を実行します。teamcity-stash プラグインを使用して結果を Stash に報告する

  • Stash を有効にして、少なくとも

    • x 承認者数
    • y 成功したビルドの数。
  • 開発者はいつでも準備ができたら、プル リクエストをメインラインに作成できます
  • すべてのプル リクエストで CI を実行し、このステータスを teamcity に報告します。ここでの利点は、プル リクエストが承認されるたびに、git がそのコミットを他のプル リクエストに自動的にマージし、すべてのプル リクエストで CI を再トリガーすることです。
  • レビュアーと承認者がコードを承認し、プル リクエストがCI を正常に通過すると、stash はプル リクエストを自動的にマージします。
  • 統合ブランチへのすべてのチェックインでビルドとテストを実行して、どのチェックインが特定のテストの失敗を開始したかを特定できるようにします (テストに許容限界がある場合)。
于 2014-08-09T21:40:13.210 に答える