タグ付けされた質問 「branch」

継続的に開発されたWebプロジェクト（製品ではない）には、現在gitフローにほぼ基づいた次の分岐戦略があります。 開発ブランチ：最新の作業バージョン マスターブランチ：リリースされるバージョン/リリースされるバージョン 機能ブランチ：開発中の機能 ホットフィックスブランチ：リリースバージョンの緊急バグ修正 マスターは読み取り専用で、開発ブランチまたはホットフィックスブランチからのプルリクエストによって更新されます。各更新により、リリース候補が構築され、ステージングシステムに展開されます。リリース候補は、手動の承認後に実稼働に展開されます。 フィーチャーブランチはオフに基づいて作成されている開発、または最後のマスターにマージされたことにコミットから。開発する機能ブランチからのプルリクエストが構築され、統合テストと受け入れテスト（自動および手動）が実行される無料のテストシステムにデプロイされます。テストとレビューに成功すると、PRはマージされ、次のリリースの一部になります（開発からマスターへのマージ）。 私の目標 これを簡素化し、開発ブランチを削除したいと思います。開発ブランチには主に歴史的な理由があり、常に正常にテストされたバージョンであるため、マスターから切り離しておく必要はないと思います。これを削除すると、追加のマージがなくなるため、リリースプロセスも簡素化されます。 次の制約があります。 リリースは予定されており、完全に自動化するべきではありません 機能ブランチは通常短命ですが、一部は数週間マージされないままになります（たとえば、再設計）が、同様にテストする必要があります（現在、開発のためのオープンプルリクエストとして） 場合によっては、通常のリリース以外で単一の機能をリリースして、事実上それを修正プログラムに変更する必要があります。現在の戦略では、機能ブランチをリベースし、直接マスターにマージできます ステージングでの外部システムとの受け入れテストが失敗した後、機能を保留する必要があることも起こります 移行についてわからない場合： 現在、テスト用のプルリクエストを作成し、リリース用のコミットをマージしています。これを統合できますか？ マスターが最新リリースより前である場合のホットフィックスの処理方法。ホットフィックスブランチからリリースを直接ビルドおよびデプロイする必要がありますか？ 既にマージされたリリースから除外されるべき機能に対処する賢明な方法はありますか？これらの場合、独立した開発ブランチは本当に利点ですか？とにかく、ほとんどの場合、手動でコミットを元に戻して元に戻すことになります。

20 git  release-management  builds  branch 

大規模な組織では、ウォーターフォール手法を使用すると、通常、非常に複雑な分岐構造（ブランチスパゲッティ）が発生します。 複雑な分岐現実からトランクベースの開発のような単一分岐モデルへの移行に使用できる分岐戦略は何ですか？ 更新： 明確にするために、質問は移行/移行自体に関するものであり、前後の方法論に関するものではなく、かなり明確です。 「今日のEOBでは、まだ数十億のブランチがある滝ですが、明日はトランクベースの単一ブランチCIに切り替えます」とは言えません。

15 continuous-integration  branch  waterfall 

大規模な組織で作業するときに、どのようにしてブランチエイジドンの状況を回避しますか？ 私たちは、ソフトウェアの更新ではなく、高/重要なセキュリティパッチとオーダーメイドの機能のみを採用するというアプローチを持つ多くの大規模な金融機関と協力しています。これらの組織は、メジャーアップデートの合間にのみパッチとカスタムリリースを取得します。メジャーアップデートは数年離れている可能性があり、コストが高くつきます。このアプローチにより、私たち（ソフトウェアハウス）は、主要な顧客ごとにコードのブランチを作成します。これには、長期ブランチのすべてのコストと非効率性が伴います。 コミュニティへの私の質問は次のとおりです。 顧客から同様のアップデート承認アプローチを経験しましたか？ このアプローチでの作業を支援するためにどのような提案がありますか？ ソフトウェアの更新を行うための組織のアプローチを変えるためにどのような提案がありますか？

10 release  process  branch 

開発とテストのための新しいステージングプロセスを作成する必要があります。 常に、活発に開発およびテストされているgitブランチは約4つだけです。各gitブランチ内には、実行する必要のあるデータベースエボリューションスクリプト（ストレートSQL）と、より重い処理のためのバックエンドからのエボリューションスクリプトがあります（これらは、データベースを実行する管理者資格情報を使用してアプリ内で呼び出す必要があるHTTPルートです）移行や、前述のプレーンなSQL進化スクリプトでスクリプトを作成することが困難または不可能であるその他の変更）。 私たちのライブDBは、適度なサイズの4.2 GBです。セットアップの準備ができて、使い捨ての真新しいDell PowerEdgeサーバーがあります。 次の質問についてのアドバイスと、経験豊富なDevOpsがこれにどのように取り組むかを知りたいです。 ステージングサーバーでいくつかの異なるブランチを実行するにはどうすればよいですか？これらのブランチは、QAに合格し、マスターにマージされて解放されると、頻繁にポップアップして消えます。 各ブランチに常に適切なDBがあることを確認するために、DB進化システムをどのようにセットアップしますか？各ブランチは、マージされるまで相互に互換性があるとは限らないさまざまな方法でDBに変更を加える場合があります。 これらのブランチを最新の状態に保つにはどうすればよいですか？各ブランチでコミットを自動プルする方法はありますか？ これをすべて設定する方法について少し迷っていますので、これ以上の入力は大好きです。現在のワークフローは関係者全員にとって困難です。開発者は完全に分離されたアプリのローカルコピーをローカルで実行しており、QAは3〜4台のラップトップをローテーションしてステージング「サーバー」として機能させます

8 git  testing  builds  branch  mysql