版本控制应该考虑哪些签入策略?

时间:2009-07-29 02:30:08

标签: version-control tfs

我的任务是帮助为我公司的TFS 2008安装设置流程模板和签入策略。

除了三个签到政策(签到操作必须对其进行评论,代码文件必须经过同行评审,必须有与签到相关联的工作项),我被要求考虑并实施任何其他人。

哪些最重要或最有用的策略可以实施版本控制?

6 个答案:

答案 0 :(得分:6)

越少越好。

通常在组织中,您希望减轻签到的摩擦,以确保您鼓励开发人员频繁进行小型离散签到,而不是一次性检查大量内容。然后,您希望确保为所有需要它的人提供可用的代码库,并捕获改善软件交付流程所需的数据。

就个人而言,执行变更集注释和工作项关联策略的策略是可以的 - 因为它们捕获的元数据当时很容易记住但之后很难找到。它还鼓励开发人员养成使用工作项来跟踪所有工作的习惯 - 甚至是实验开发或尖峰。

使用分支或其他流程可能会更好地执行同行评审流程,而不是在每次签入时强制进行同行评审 - 但这取决于您的流程。还要记住,您可以在TFS中使用强制性的签到注释来捕获元数据,例如代码审阅者。办理登机手续的票据与办理登机手续的政策略有不同,而且经常会混淆。

如果您想阅读有关签到政策的更多讨论,请查看blog post I did on the balancing act a while ago。另外,为了听到关于签到策略的更多讨论,我最近录制了一个播客,其中一个Team System MVP讨论了他们对TFS的使用,这可能很有趣(Radio TFS, Using TFS with Ed Blankenship)。最后,我们在2008年也做了Radio TFS episode all about check-in policies,可能会感兴趣。

答案 1 :(得分:2)

我们公司遵循的一些规则:

  • 一次提交与同一任务相关的所有更改(这将有助于查看更改以及将来的回滚或合并,如果需要)。
  • 基于模板的评论(例如:使用代表所做内容的代码为所有评论添加前缀,为添加添加+, - 用于删除,*用于更新,用于重要修改等)。
  • 显然总是签到代码编译,并完成工作到主线。
  • 每天将未完成的工作登记到分支机构。

答案 2 :(得分:2)

不要破坏构建!当然,找到一种自动检查方式并拒绝办理登机手续是一项挑战。

答案 3 :(得分:2)

我在TFS工作的地方使用的是:

  • 代码分析
    • 这确保在检入
    • 之前,所有代码都在开发者机器上编译
  • 工作项目关联
    • 如果您已完成更改,则应该已分配任务!
  • 最后建立成功
    • 使用TFS Build Server检查在独立计算机上编译的源代码管理中的当前代码
  • 签入评论(TFS Powertools的一部分 - http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx
    • 能够在不必去工作项目的情况下查看办理登机手续的摘要是件好事

答案 4 :(得分:1)

尽量减少在同一分支上工作的开发人员的数量。这样,分支在编译,单元测试和回归方面保持稳定。如果开发人员进行了检查,但是他的代码会破坏应用程序的关键区域(例如登录),那将是一场噩梦。

如果您真的必须有超过10位开发人员将代码检入同一分支,我们已经启动了一个电子邮件策略,其中开发人员检查警告每个人他们正在检入,以便没有人尝试更新他们的副本在办理登机手续的时候,我们必须要有相反的情况,我们在日期留出时间禁止登记,以便更新是安全的。

答案 5 :(得分:0)

坦率地说,政策越少越好。您拥有的策略越多,不使用版本控制的动机就越大。那么会发生什么:

  • 代码是在并行的,不受控制的源代码控制系统上开发的,最后修订版仅供官方版本使用。
  • 人们会尽可能地延迟投入,降低他们对其他开发人员所做工作的可见性。
  • 如果人们可以侥幸逃脱,人们实际上会避免犯下任何东西,而且有些人会找到逃脱它的方法。

事实上,我认为你的三张登记政策已经太多了。例如:

  • 在办理登机手续之前对代码进行同行评审会使在那里存储的工作变得更加困难。相反,如果源控制系统允许它(许多人都这样做),则控制源是否经过同行评审。对于某些系统,您可以为修订创建生命周期,其他人可以创建分支,还有一些系统可以使用标记。
  • 如果工作项与签入相关联,则开发人员无法进行探索性编程或主动进行可能的改进。它扼杀了开发人员。相反,请确保进入集成测试或用户验收测试的任何修订,更不用说生产本身,与工作项相关联。

这可能听起来反企业,但这只是我们在几十年的软件开发中学到的一些东西。大多数企业组织都没有对此有所了解,但最终他们会这样做。所以,你可能会采取相反的方式,但不要说没有人告诉过你。

我建议使用Agile Manifest,特别是Lean Software Development作为一般原则。

或者,考虑到Stack Overflow设计理念,让系统奖励你想要的行为。