项目/代码发布策略

Question

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

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

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

问题：为了达到某种程度 - 您建议采用哪种策略来确保发布所需的流程和工作尽可能顺利进行？我们正在使用git进行版本控制，maven用于我们的构建系统，并且我们有bug跟踪和持续集成系统运行，所以我相信工具就在那里。我只是不确定适当的发布过程应该是什么样的。

Answer 1

你有三个位置：版本控制，通过Maven和连续构建服务器一键构建，以及错误跟踪。听起来你们都倾向于采用敏捷方法，所以你应该一直试图将产品的主干版本保持在接近可交付的状态。

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

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

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

Answer 2

  

一位开发人员发现的问题是   其他开发人员无法复制，   和一个版本中发现的问题可能会   在下一个消失（或更糟，新的   问题可能出现）。这使得a   非常令人沮丧的经历   有责任的人   整合所有项目和   确保质量和性能   符合标准 - 即我自己。

     

潜在的解决方案：我个人而已   我们确信我们需要更好地执行   结构通过固定版本号   和定期发布。

我认为你不需要经常发布内部协调。您可以通过版本控制来实现。报告问题时，让人们谈论具体的git修订。另请注意，您还必须协调任何外部依赖项/库。某种vendor branches可以帮助解决这个问题。

Answer 3

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

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

Answer 4

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

我认为您将从定义代码库的规范视图中受益。称之为测试。如果问题出现在Test中，则问题是一个问题。如果某个开发人员的观点中没有出现问题，那么开发人员需要弄清楚重要的区别是什么;同样也适用于开发人员视图中出现的问题，但不适用于测试。

一种惯例是每晚从源头重建测试。更艰苦的约定是每次更新时都要重新构建Test。如果您的团队规模很小（五个或更少）并且没有分散在很远的距离或多个时区，那么合理的第一个近似是在已安装工具链的服务器上测试一个git工作区以及一些cron作业，以便这个工作空间每晚（通常）更新和重建。