项目/代码发布策略

Question

背景：我在一家传统上从事研究型工作并且没有太多商业空间经验的小型软件公司工作。我们现在正试图进入商业世界。由于我们研究的起源，我们习惯于非常快速的开发周期以及在维护适当版本的项目方面很少的结构。

问题：由于每个开发人员对代码库的看法略有不同，所以缺乏结构现在被证明是有点阻碍的。一个开发人员发现的问题不能被另一个开发人员重现，并且在一个构建中发现的问题可能在下一个消失（或者更糟糕的是，可能出现新问题）。这对于负责整合所有项目并确保质量和性能标准得到满足的人来说是非常令人沮丧的体验 - 即我自己。

可能的解决方案：我个人认为，我们需要通过固定版本号和常规版本实施更好的结构。不言而喻，正确的版本控制如何能够解决我们许多问题，但这当然不是没有问题 - 开发人员需要做额外的工作来执行和测试版本，并且不再能够使用最新版本的一切。

问题：为了说明问题 - 您推荐哪种策略来确保发布所需的流程和工作尽可能流畅地进行？我们使用git进行版本控制，maven用于构建系统，并且我们运行了错误跟踪和持续集成系统，所以我相信这些工具就在那里。我只是不确定正确的发布过程应该是什么样子。

Answer 1

您拥有三大版本：版本控制，通过Maven一键构建，持续构建服务器以及错误跟踪。这听起来像你们正在倾向于敏捷方法论，所以你应该努力保持产品的主干版本始终处于可交付状态。

当您决定制作第一个版本时，请为该版本的干线版本创建一个分支。决定一个标签方案，并确保标签的分支版本。例如，您的第一个版本可能是1.0.4530，其中1表示第一版本，0表示它是第一版本候选版本，4530是版本控制更改编号。您测试此版本分支并修复它的重要错误。过了一段时间，你发布另一个候选版本，比如1.1.4807。这个过程重复多次（比如说），你的版本变得足够好，并且你发布了1.3.5167版本。

同时，您的新开发仅发生在中继版本中，您不时需要将1.x版本分支中的错误修复合并回中继。稍后，您将从中继分出一个2.x分支，以重复第二次发布的过程。你通常会有几个活跃的分支（加上干线），发展局限于干线，每个分支保持原始状态，独立于开发。

你们会得到一些东西，你们的开发者协调问题会变得不那么频繁。但是这些问题几乎都只限于主干，而不是发布分支。

Answer 2

一个问题一个开发商发现是 没有其他开发人员可重复的，在一个构建中发现，在未来可能 消失 和问题（或者更糟，可能会出现新的问题 ）。这使得 非常令人沮丧的经验 谁负责 整合所有项目和 确保质量和性能 标准符合 - 即我自己。

潜在的解决方案：我个人认为我们需要通过固定版本号 和常规版本来执行更好的 结构 。

我不认为你需要有非常频繁的发布来协调内部。你可以通过版本控制来做到这一点。在报告问题时，只需让人们讨论特定的git修订版。另外请注意，您也必须协调任何外部依赖项/库。某种vendor branches可以帮助解决这个问题。

Answer 3

有一些关于一般话题的书籍;亚马逊搜索甚至返回三个标题专门用于“使用git进行版本控制”。

我想你会受益于定义代码库的规范视图。称它为测试。如果它出现在测试中，则问题是一个问题。如果某个开发人员认为某个问题没有出现，那么由开发人员来确定哪些是重要区别;同样对于出现在开发者视图中的问题，而不是在测试中。

一个约定是测试每晚从源重新构建。更严格的惯例是在每次更新时重新构建Test。如果您的团队规模较小（五个或更少），并且不会分散在很远的距离或多个时区，合理的第一个近似方法是在安装了工具链的服务器上测试git工作区以及一些cron作业，以便该工作区每晚更新和重建（通常）。

Answer 4

这听起来像开发人员需要使用“测试分支”，并更多地尊重“稳定/生产分支”。

出售的概念是“在这个分支做你的狂野西部的东西”，当你对结果感到满意的时候，你将它合并到这个“无聊的稳定生产分支”中......或者类似的东西）