解决团队之间代码冲突的最佳实践

时间:2014-05-22 02:43:55

标签: testing integration-testing branching-and-merging

我正在寻找合并代码时可能出现的以下场景的解决方案:

  • 代码中存在基本冲突,A队和B队都更新同一个文件,然后报告为冲突。
  • 如果团队A开发了导致与团队B功能冲突的选定功能,则存在功能冲突
  • 存在性能问题,A团队开发的变更工作正常,但B团队的变更会导致团队A的功能受到影响。

在最终发布方面,谁负责从双方最终交付集成包?

在发布期间,双方都将面临交付压力的压力。如果发生代码冲突,那么解决它们的过程是什么?如果A队先检查,B队然后识别一些代码冲突,根据下面的标准方法,他们将解决冲突。谁负责变更,因为双方都将在系统测试环境中测试他们的代码并验证变更?但是,在SIT(系统集成测试)之前,不会对这两种变化进行综合测试。因此,如果B队已更改代码以解决A队更改中的冲突,则会使已发生的任何测试失效,并且他们可能无法正确地完全测试要求。

1 个答案:

答案 0 :(得分:1)

目前的最佳做法是拥有一个自动化测试套件,可以彻底测试整个应用程序的所有功能。 (将测试推迟到开发后发生的集成测试阶段绝对不是最佳实践。)

  • 当任何开发人员更新代码时,开发人员有责任更新测试(在同一个提交中)以测试她的更改并确保所有测试都通过。这包括性能测试。

  • 任何更新之后,所有使用该代码的开发人员都应该尽快将更新提取到他们的工作区中。每个开发人员负责解决其更改与存储库中代码的最新版本之间的任何源代码冲突,并确保所有测试都通过。通常不同的开发人员在代码的不同部分工作,不会有冲突。如果存在非平凡的冲突,则可能意味着两个开发人员应该一起工作。他们应该决定下次做得更好。

关于交付,目前的最佳做法是随时可以交付主分支。如果所有测试都通过,我们就知道该软件已准备就绪。因此,在开发方面无需提供任何软件。如果要将软件交付给客户,最好的人选是产品所有者或产品经理,他们将根据业务需求做出决策。事实上,在可能的环境中(例如Web应用程序),最佳实践是自动提供所有测试通过的软件的每个版本。