受控/促销分支有价值吗？
我从事 SCM 工作，使用各种工具（Subversion、Clearcase、TFS、Perforce）和技术（主要是 .NET、Java）。在我开始工作之前，正常的业务顺序是创建一个受控分支机构。
我将受控分支定义为： - 一个单独的分支，其中包含开发人员无法访问的升级代码。只有构建工程师团队才能访问此内容。
受控构建： -构建引擎，从受控分支获取代码并生成开发人员无法修改的工件。
因此，合并到该分支已成为受控构建过程的重要一步。这可能会产生速度和错误这两方面的问题（这主要可以通过自动化来缓解）。
好处： 自动代码锁定（因为开发人员无法修改分支） 分支名称可以不同（其他团队不一定遵循标准化做法，我们也不一定能够施加所需的压力。） 找出确切版本代码状态的简单方法（即某个版本的受控分支中的最新代码是生成的代码）
缺点： 速度 在与开发人员讨论问题时，将开发版本与受控版本相匹配（这是自动化的，但有点混乱）。 错误（过程中另一个混乱的地方） 使用变更列表/变更集/不可变标签可以完全处理安全/角色分离功能吗？
问题：
我是否应该建议放弃当前的受控分支策略？我还缺少其他好处吗？
I'm in SCM and work with a variety of tools (Subversion, Clearcase, TFS, Perforce) and technologies (.NET, Java mostly). Before I started work, the normal order of business was to create a controlled branch.
I define controlled branch as:
-A separate branch which contains promoted code which developers are unable to access. Only a team of build engineers have access to this.
Controlled build:
-Build engine which takes code from controlled branch and produces an artifact developers are unable to modify.
As a result, merging into this branch has become a significant step as part of a controlled build process. This can create both issues with speed and errors (which will be mostly mitigated by automation).
Benefits:
Automatic Code Lock (since devs can't modify branch)
Branch names can be different (other teams don't necessarily follow standardized practices and we are not necessarily able to exert the required pressure.)
easy way to find out exact version code state (i.e. latest code in controlled branch for a version is what went to prod)
Drawbacks:
Speed
matching dev builds with controlled builds when discussing issues with developers (this is automated, but a little messy).
Errors (another place to mess up in the process)
Can the security/role separation functionality be fully handled by using changelists/changesets/immutable labels?
Questions:
Should I recommend moving from the current controlled branch strategy? Am i missing other benefits?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不建议使用分支作为升级机制，除非您打算对合并到所述分支的标签进行大量修改。
分支应该隔离开发工作（即修改文件和提交新版本的内容）
与某种元数据（ClearCase 属性、SVN 属性、Git 注释等）关联的标签应该足以通过以下方式监控所述标签（及其不可变内容）的升级：各种促销级别。
I wouldn't recommend using branches as promotion mechanism, unless you intent to do lots of modifications from the label being merged to said branch.
A branch should isolate a development effort (i.e. something where files are modified and new versions committed)
A Label associated with some kind of metadata (ClearCase attributes, SVN properties, Git notes, ...) should be enough to monitor the promotion of said label (with its immutable content) through the various promotion levels.
我们使用受控分支（MAIN）作为我们的官方构建分支。开发人员只能通过开发分支的合并操作来访问该分支。此外，MAIN 分支代码被合并到 BUGFIX 分支（专门用于我们当前版本软件的错误修复）和 PROD 分支（其中代码按每个版本进行标记）。
我认为，任何为了测试（以及最终）生产目的而构建的东西都不应该有临时的开发人员访问权限，而应该由 SCM 经理或其他类型的图书馆员角色来管理。
当我们的 MAIN 分支中确实存在构建问题时，我们也坚持让开发人员在开发分支中修复这些错误，并将解决方案合并回我们的 SCM 策略中的 MAIN 中。
We use a controlled branch (MAIN) as our official build branch. Developers are only permitted access to this branch through merging operation from the development branch. Furthermore, MAIN branch code is merged to a BUGFIX branch, which is dedicated to bugfixes for our current release of software, and a PROD branch, where the code is labeled on a per-release basis.
I am of the opinion that anything that is going to be built for testing (and ultimately) production purposes should not have casual developer access, and should be managed by a SCM manager or other type of librarian role.
When we do have build issues within our MAIN branch, we are also adamant about having those bugs fixed within the development branch by the developers and having the resolution merged back into MAIN within our SCM policies.