0

現在、さまざまなプロジェクトに複数のGitリポジトリがあります。

現在、次のワークフローがあります。マスター-ここですべてのコミットをデプロイ-ライブサーバーで使用される本番コード

新しいコミットごとにHudsonciチェックマスターがあります。変更を毎分ポーリングします。また、マスターブランチからデプロイする前に、物理機能をテストする作業要求をサインオフするためのステージングサーバーもあります。

現在私たちが直面している主な問題は、チケット/作業要求ベースで作業していることです。すべての変更をリリースベースで展開したいとは限らない場合がありますが、チケットが上級スタッフからサインオフされた場合はいつですか。

Gitフローやgithubフローなどを見てきました。どちらにも利点がありますが、ステージングサーバーとciを含める戦略を見つけることができませんでした。

読書のための助けや推奨事項は大歓迎です！

更新1

ワークフローは次のとおりです。

Production:  -------------I-----------O----
                         /           /
             B---E---F---G    J---K---L
Master:  A--/--C---D---H--\--/---M---N-\---
          \-1-/-2-/-3-/     \-1-/-2-/

Ciとステージングエリアはすべてマスターから実行されます。すべての作業はブランチで実行され、ステージングにマージされます。サインオフ時に、機能/チケットブランチからの作業が本番環境にマージされ、特定のブランチ内で行われた変更のみが行われます。

これが間違っている場合、または誰かがこれに対するより良い解決策を持っている場合は、私を修正してください

4

1 に答える 1

1

つまり、マスターブランチがあり、コミットはprodとステージングブランチに送られ、コミットはステージングサーバーに送られます。

ですから、これは私には理にかなっています。各チケットは、マスターから離れた独自のブランチである必要があります。そこから、開発者はステージングにマージしてそこでテストできます。テストに合格してサインオフしたら、そのブランチを使用できます。そこから、「リリース」ブランチにマージするブランチを決定し、そのブランチをマスターにマージしてデプロイできます。

リリースブランチをステージングにマージして、そこでリリースをもう一度テストし、各ブランチが他のブランチとうまく機能することを確認することもできます。

または..githubを使用している場合は、チケットに基づいて各開発ブランチを新しいブランチから切り離すだけです。次に、PRをマスターに送信します。

于 2012-07-22T15:42:50.483 に答える