背景:我在一家小型软件公司工作，该公司传统上从事研究型工作，在商业领域没有太多经验。我们现在正在努力进军商业领域。由于我们的研究起源，我们习惯于非常快速的开发周期和在维护项目正确版本方面的很少的结构。
问题:事实证明，缺乏结构在某种程度上是一种障碍，因为每个开发人员对代码库的看法都略有不同。一个开发人员发现的问题不能被另一个开发人员重现，并且在一个构建中发现的问题可能会在下一个构建中消失(或更糟糕的是，可能会出现新问题)。对于负责整合所有项目并确保满足质量和性能标准的人(即我自己)来说，这会是一次非常令人沮丧的经历。
潜在的解决方案:就我个人而言，我确信我们需要通过固定版本号和定期发布来实现更好的结构。不言而喻，正确的版本控制将如何帮助解决我们的许多问题，但当然它也不是没有问题 - 开发人员需要做额外的工作来执行和测试版本，并且将不再能够使用最新版本的一切。
问题:归根结底 - 您建议采取哪些策略来确保发布所需的流程和工作尽可能顺利进行？我们使用 git 进行版本控制，使用 Maven 进行构建系统，并且我们运行错误跟踪和持续集成系统，所以我相信这些工具就在那里。我只是不确定正确的发布流程应该是什么样子。
最佳答案
您已经具备了三大要素:版本控制、通过 Maven 和持续构建服务器进行一键构建以及错误跟踪。听起来你们正在倾向于敏捷方法论，因此您应该努力使产品的主干版本始终保持在接近可交付的状态。
当您决定发布第一个版本时，请为该版本创建主干版本的分支。确定标记方案并确保标记分支版本。例如，您的第一个版本可能是 1.0.4530，其中 1 表示第一个版本，0 表示它是第一个候选版本，4530 是版本控制更改编号。您测试此发行分支并修复其上的重要错误。一段时间后，您发布另一个候选版本，例如 1.1.4807。这个过程再迭代几次(比如说)，您的版本变得足够好，并且您发布了版本 1.3.5167。
同时，您的新开发仅发生在主干版本中，并且有时您需要将错误修复从 1.x 版本分支合并回主干。稍后，您将从主干中分离出一个 2.x 分支，以便为第二个版本重复该过程。您通常会有几个活跃的分支(加上主干)，开发仅限于主干，每个分支保持原始状态并独立于开发。
你们会掌握窍门，开发人员协调问题也会变得不那么频繁。但这些问题几乎都仅限于主干，而不是发布分支。
关于language-agnostic - 项目/代码发布策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/954281/