2

この投稿 (ブランチを使用する中規模のプロジェクトでデータベースのリビジョンを管理するにはどうすればよいですか? ) を読んで、ブランチを使用して Web プロジェクトで作業し、開発、ステージング、および運用 (ローカル コピーと共に) にデプロイする最善の方法を考えさせられました。

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

これが私たちのやり方で、ちょっともろく感じます (現在は svn を使用していますが、git への切り替えを検討しています):

  1. 2 つの「ブランチ」 - STAGE の特定のリリースが TRUNK としてマークされている DEV と STAGE
    • 開発者は変更ごとに TRUNK のコピーをチェックアウトし、そのブランチを作成します
    • 開発者はローカルで作業し、コードを頻繁にチェックインします (投票のように: 早期かつ頻繁に)
    • 開発者が完全に壊れていないことに慣れたら、ブランチを DEV にマージし、開発サイトにデプロイします。
    • 変更が「終了」するまで、必要に応じて 3 ～ 4 を繰り返します。
    • 変更ブランチを STAGING にマージし、ステージ サイトにデプロイします。期待される最終テストを行います。
    • 一定期間後、STAGE の特定のリビジョンを TRUNK としてマークし、トランクをライブにプッシュします。
    • TRUNK の変更を DEV にマージして同期を維持する

現在、これらのステップのいくつかは非常に複雑であり、実際には実行が非常に困難です (TRUNK -> DEV は常に壊れます)。そのため、もっと良い方法があると想像する必要があります。

考え？

4

4 に答える 4

2

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

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

全体として、より良いとは、ブランチが少なく、タスクが短く、リリースまでの時間が短く、テストが多いことを意味します。

于 2008-10-01T19:21:08.743 に答える
1

TRUNK->DEV の最終的な影響を最小限に抑えるために、より多くの「リベース」(「親」環境 STAGE から「子」環境「DEV」、開発者ブランチへのマージをより頻繁に行う) が当然の考えですが、これは必要ありません。もう。

つまり、STAGE で行われ、一度に本番環境 (TRUNK) に入る必要があるものはすべて、できるだけ早く DEV およびプライベート devs ブランチにマージする必要があります。

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

于 2008-10-01T04:20:23.540 に答える
1

これを読んでください：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

于 2009-04-15T23:51:14.487 に答える
0

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

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

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

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

于 2008-10-01T04:26:47.427 に答える