Webアプリのソースコード管理戦略-分岐、タグ付け、分岐など-

StackOverflow https://stackoverflow.com/questions/156120

質問

この投稿（ブランチを備えた中規模プロジェクトのデータベースリビジョンをどのように管理しますか？）ブランチを使用し、（ローカルコピーとともに）開発、ステージング、およびプロダクションにデプロイするWebプロジェクトでどのように作業するのが最善か疑問に思いました。

「リリース」はありません。それ自体：機能が目立つほど大きい場合、ライブでプッシュします（必要なテストなどの後）、そうでない場合は数回バッチ処理し、「快適」と感じたらそれらをライブでプッシュします。常に変化するサイトはユーザーを少し不安にさせる傾向があるため、目標は1か月に1、2回以上は展開しないことです。

これを行う方法を次に示します。これは一種の脆さを感じます（現在はsvnを使用していますが、gitへの切り替えを検討しています）：

  1. 2つの「分岐」 -TRUNKとしてマークされたSTAGEの特定のリリースのDEVおよびSTAGE
    • 開発者は変更ごとにTRUNKのコピーをチェックアウトし、ブランチを作成します
    • 開発者はローカルで作業し、コードを頻繁にチェックインします（投票と同じように、早期かつ頻繁に）
    • デベロッパーが完全に壊れていない場合は、ブランチをDEVにマージして開発サイトにデプロイします。
    • 変更が「終了」するまで、必要に応じて3-4を繰り返します
    • 変更ブランチをSTAGINGとマージし、ステージサイトにデプロイします。予想される最終テストを行います。
    • しばらくしてから、STAGEの特定のリビジョンをTRUNKとしてマークし、トランクをライブプッシュします
    • TRUNKの変更をDEVにマージして同期を保つ

現在、これらのステップのいくつかは手作業で大幅に複雑化されており、実際には実行が非常に難しいため（TRUNK-＆gt; DEVは常に中断します）、より良い方法があることを想像する必要があります。

思考？

役に立ちましたか？

解決

ブランチは、作業が予定通りに完了せず、継続的なインテグレーション作業を行うための十分なテストがない場合に便利です。プログラミングタスクが大きすぎて予測どおりに完了できないショップでは、ブランチクレイジーな開発を目にする傾向があります。そのため、管理者はリリースの直前までどの機能を出荷すべきかを判断したいと考えています。そのような作業をしている場合は、分散バージョン管理の使用を検討することをお勧めします。すべての作業ディレクトリは自然にブランチであり、誰も傷つけることなく食べることができるすべてのローカルチェックインとローカル履歴を取得できます。トランク外の他の開発者とクロスマージすることもできます。

私が好むのは、リリース候補のブランチを持つ不安定なトランクで作業するときです。ブランチはリリース用にタグ付けされ、緊急パッチのストリームになります。このようなシステムでは、3つ以上のブランチ（最後のリリース、現在のリリース候補、不安定なトランク）がほとんどありません。これは、TDDを実行していて、不安定なトランクにCIがある場合に機能します。また、すべてのタスクを分解して、必要な頻度でコードを配信できるようにする必要がある場合（通常、タスクは1〜2日間で、その機能を構成する他のすべてのタスクなしでリリース可能です）。そのため、プログラマは作業を行い、トランクをチェックアウトし、作業を行い、すべてのテストに合格したときに同期してチェックインします。不安定なトランクは、リリース候補としてブランチに常に利用可能です（すべてのテストに合格した場合）。したがって、リリースは非イベントになります。

全体として、より良い意味：ブランチの数を減らし、タスクを短くし、リリースまでの時間を短くし、テストを増やします。

他のヒント

明白な考えは、「リベース」することです。 TRUNK-＆gt; DEVの最終的な影響を最小限に抑えるために、「親」環境STAGEから「子」環境「DEV」から開発者ブランチに頻繁にマージします。

つまり、STAGEで行われ、一度に実稼働に入る（TRUNK）ものはすべて、DEVとprivate devsブランチでできるだけ早くマージする必要があります。そうしないと、これらの最新のレトロフィットマージは常に苦痛になります。

しかし、上記のマージワークフローはあまりにも不便です。リリース直後の最新のDEVに基づいて、REBASEブランチを提案します（新しいTRUNK）。リベースTRUNK-＆gt; DEVはTRUNK-＆gt; REBASEになり、すべての問題が解決されます。次に、最終的なマージDEV-＆gt; REBASEを実行して、現在のdevが新しい更新システムと互換性があることを確認します。 REBASEからDEV（およびプライベートdevブランチ）への最後の些細なマージがプロセスを完了します。
ブランチのポイントは、他の現在の開発作業と一緒に実施できない開発作業を分離することです。 TRUNK-＆gt; DEVが複雑すぎて現在のDEVに対応できない場合は、分離する必要があります。したがって、「REBASE」ブランチ命題。

私は職場でSVNを使用しています。 C ++開発を行っている間、バージョン管理は非常に普遍的です。以下は私たちのアプローチです。もしあれば、どのアプローチがあなたのアプローチにとって妥当かを決めることができます。

私たちにとって、すべての開発はブランチで行われます。すべてのバグと機能ごとに分岐しています。理想的には、そのブランチは1つの機能のみに専念しますが、それが意図されていない場合もあります。

作業が完了し、テストされ、「準備完了」したとき変更をトランクにマージします。私たちのルールは、トランクのコードが壊れてはならないということです。壊れたコードがトランクに到達する場合、それを修正することが優先度1になります。

すべての機能が完了してマージされると、リリースが行われます。リリース用のブランチがタグとして作成されます。このタグを使用すると、必要に応じてスナップショットを取得できます。このブランチにより、以前のバージョンのサポートが可能になります。リリースされたバージョンのバグを修正するには、そのリリースのブランチに移動し、そこから分岐します。すべてがうまくいくと、変更はリリースのブランチにマージされ、必要に応じてトランクに至るまでマージされます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top