标准分支计划中的服务分支 [英] Servicing Branch in Standard Branch Plan

问题描述

关于标准分支计划，我有一个非常简单的问题.

I have a very simple question regarding the Standard Branch Plan.

我了解分支，FI和RI等.我不太了解如何在实践中使用Servicing分支.

I understand branching, FI and RI, etc.  What I don't quite understand is how to use the Servicing branch in practice.

我的理解是，当发布时，我将Main-> R1.SP1分支(例如，假设这是我的第一个版本)，然后立即将R1.SP1分支到R1.然后将R1设置为只读.我完全理解并喜欢这个.

My understanding is when it comes time to release, I branch Main -> R1.SP1 (assuming this is my first release, for example) and then immediately branch R1.SP1 to R1.  Then set R1 to Read Only.  This I completely understand and like.

这是我不了解的东西:R1.SP1，R1.SP2，R1.SP3如何以及何时创建?

Here's what I don't understand:  How and when do R1.SP1, R1.SP2, R1.SP3 get created?

随着时间的流逝，我是否将RI SP1 RI返回主节点，然后将主节点分支到SP2/3/n?

Do I RI SP1 back to main and then branch main to SP2/3/n as time goes on?

用另一种方式说，这些将来的SP如何对其自身的发布/部署进行更改?

Said another way, how are these future SPs populated with changes for their own release/deployment?

例如，如果客户报告R1中的错误，我应该在哪里签出代码以进行更改，又应该在哪里签入/提交更改/固定的代码?我是否可以签入SP1分支? (因为R1分支是只读的).那怎么了

For example, if a customer reports a bug in R1, where do I check code out from to make this change and where do I check in/commit the changed/fixed code back into?  Do I check in to the SP1 branch? (Because the R1 branch is read only).  Then what? 

我想我要问的是，我的可持续发展在哪里发生，以为R1创建未来的SP，以及如何为它们自己的发布/部署创建和准备这些SP?

I guess I am asking where is my sustaining development happening to create the future SPs for R1 and how do these get created and prepped for their own releases/deployment?

一个非常简单的分步方案示例将是最有帮助/赞赏的.

A very simple step by step scenario example would be most helpful/appreciated.

请，如果我的问题不清楚，请告诉我，我会尽力进行修改.

Please, if my question is not clear, let me know and I will do my best to revise it.

推荐答案

不是TFS专家，但我读到的是:

Not a TFS specialist, but what I read is:

1. 开发人员只需根据更改所针对的发布媒介签入一次(即，修补程序将进入产品HOTFIX分支).
2. 无需进行无基础的合并.通过基于发布工具创建分层分支结构，创建回到MAIN的自然合并路径.
3. 降低回归风险.通过在MAIN->SP->和HOTFIX分支之间创建父/子分支关系，更改自然会合并到将来的版本中(即Hotfixes在进入MAIN的过程中合并到SP分支中)，从而减少了bug回归的风险.未来的版本.

1. Developers only need to check in once based on which release vehicle the change is for (i.e. Hotfixes go into the product HOTFIX branch).
2. No need for baseless merges. Create a natural merge path back to MAIN by creating a hierarchal branch structure based on your release vehicles.
3. Reduce risk of regressions. By creating a parent/child branch relationship between MAIN->SP-> and HOTFIX branches changes are naturally merged into future release (i.e. Hotfixes merge into the SP branch on their way to MAIN) reducing risk of bug regressions in future releases.

在创建发布分支后，从MAIN进行的更改不应将(FI)合并到发布分支中.
更改应以一种方式从RELEASE合并为MAIN.
此外，更改应始终通过中间分支合并(即RELEASE-> HOTFIX-> SERVICEPACK-> MAIN)，以确保错误修复在后续版本中保持一致.

After the release branches are created changes from MAIN you should not merge (FI) into the release branches.
Changes should merge – one way – from RELEASE to MAIN.
Also, changes should always merge through intermediate branches (i.e. RELEASE -> HOTFIX -> SERVICEPACK -> MAIN) to ensure that bug fixes remain consistent in subsequent releases.

我认为最后一部分明确提到了将版本发布到生产环境后，合并的工作流程应该如何进行.
它应该回到主要状态，直到进行了足够的整合以创建新的船用车辆集(从维修阶段，从中选择启动新SPx的版本，到Hoyfix.spx，再到release.spx)

I think that last section explicitly mentions how the workflow of merges should go once a version has been released into production.
It should go back to main until enough has been consolidated in order to create a new set of ship vehicles (from servicing, where you choose a version to start your new SPx, to Hoyfix.spx, to release.spx)

OP user1448758 在评论中指出了文章 我在哪里修复生产缺陷? 其中提到:

The OP user1448758 points out in the comment the article Where do I fix a production defect? which mentions:

Release分支是hotfix或servicing分支的子级，而不是单独的分支结构. 这使您可以为需要并行支持的每个次要或主要版本拥有多个活动版本集(由Service Pack，Hotfix，Release分支组成).
> 该修补程序将应用于发现该错误的特定版本，然后合并(RI)到Main并可能合并到vNext开发分支中.

The Release branch is a child of the hotfix or servicing branch, rather than in a separate branching structure. This allows you to have multiple active release sets (consisting of Service Pack, Hotfix, Release branches) for each of the minor or major releases you need to support in parallel.
The hotfix would be applied to the specific release the bug is found in, and then merged (RI) to Main and possibly into vNext development branches.

由于发布vCurrent后开发分支正在处理vNext的工作，因此我不鼓励您修复vNext开发分支中vCurrent(发布后)中发现的缺陷.
发布Sprint 1之后，应该在 release 侧修复Sprint 1中的缺陷(发布后)，并在development上修复Sprint 2中的错误(发布前).侧面(vNext).

Since the development branches are working on vNext work after vCurrent is released, I discourage you from fixing defects found in vCurrent (post-release) in the vNext development branch.
After you release Sprint 1, you should fix defects (post-release) in Sprint 1 on the release side, and fix bugs (pre-release) in Sprint 2 on the development side (vNext).

Release是hotfix 的子级. 在创建发行版时，hotfix和发行版的内容相同.
Release设为只读，并且Hotfix可用于针对已发布的内容进行缺陷修复.

Release is a child of hotfix. At the time you create the release, the contents of hotfix and release are the same.
Release is made read-only and Hotfix is available for making defect fixes against what was released.

反转结构的问题是，如果不通过Release，就不能将hotfix移到Main，这意味着您不再拥有已发布代码的副本.

The problem with inverting the structure, is you cannot move a hotfix to Main without going through Release, and doing so means you no longer have a copy of the code as released.

这篇关于标准分支计划中的服务分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！