Language agnostic 项目/代码发布策略

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

问题：缺乏结构现在被证明是一个障碍，因为每个开发人员对代码库的看法都略有不同。一个开发人员发现的问题不能由另一个开发人员重现，并且在一个构建中发现的问题可能会在下一个构建中消失（或者更糟的是，可能会出现新的问题）。对于负责整合所有项目并确保达到质量和性能标准的人来说，这是一次非常令人沮丧的经历——例如我自己

潜在的解决方案：我个人认为，我们需要通过固定版本号和定期发布来实施更好的结构。不言而喻，适当的版本控制将有助于解决我们的许多问题，但当然也不是没有问题——开发人员需要做额外的工作来执行和测试发布，并且将不再能够使用所有内容的最新版本

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

开发人员发现的一个问题是 不可由其他开发商复制， 在一次构建中发现的问题可能 在下一次（或更糟的是，新的）中消失 可能出现问题）。这是一个很好的例子 这是一次非常令人沮丧的经历 对……负责的人 整合所有项目和 确保质量和性能 符合标准-即我自己

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

---

我认为你不需要为了内部协调而频繁发布。您可以通过版本控制来实现这一点。只是让人们在报告问题时谈论特定的git修订。还要注意，您还必须协调任何外部依赖项/库。有些人可能会对此有所帮助。

有些书是关于一般主题的；Amazon搜索甚至返回三个专门的“git版本控制”标题

我认为您将从定义代码库的规范化视图中获益。称之为测试。如果问题出现在测试中，那么它就是问题。如果某个问题没有出现在某个开发人员的视图中，则由该开发人员来找出重要的区别；同样，对于出现在开发人员视图中但不在测试中的问题

---

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

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

销售“在这个分支中做你的西部狂野”的概念，当你对结果感到满意时，你就把它合并到这个“无聊的稳定生产分支”。。。。

---

（或者类似的东西）

您有三大功能：版本控制、通过Maven和连续构建服务器一键构建，以及bug跟踪。听起来你们都在向敏捷方法论靠拢，所以你们应该努力让产品的主干版本始终处于一种近乎可交付的状态

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

同时，您的新开发只在主干版本中进行，并且不时需要将1.x发行版分支中的错误修复合并回主干。稍后，您将从主干中分离出一个2.x分支，以便在第二个版本中重复该过程。通常会有几个活动分支（加上主干），开发仅限于主干，每个分支保持原始状态，独立于开发

---

你们将掌握一些诀窍，开发人员协调问题将变得不那么频繁。但这些问题几乎都将局限于主干，而不是发布分支。

供应商分支看起来很有趣。谈论特定的修订并不是一个真正的选项，因为我们每天有50多个项目提交，所以要求我们的开发人员不断枚举和同步版本将花费大量的时间。通过标记/分支表示的版本号将使同步过程更加容易。