在http://semver.org/阅读语义版本控制后，我决定使用以下模式。但是，在自动化和集成SDLC工具方面，我脑子里有一些未解决的问题。
版本模式：
的 major.minor.revision.build
这样;
专业：重大变化，应手动增加。
只要在问题跟踪系统中解决了新功能或现有功能的增强功能，次要次要更改就会自动增加。
修订：不会影响次要更改的更改，应在问题跟踪系统中解决错误时自动增加。
假设开发人员从不提交源，除非在问题跟踪系统中解决了问题，并且问题跟踪系统在此配置中是JIRA。这意味着除了任务之外，默认情况下还存在作为问题类型的错误，改进和新功能。
此外，我在这个配置中添加了一个连续的集成工具，并假设它是竹子（顺便说一下，我之前从未使用过竹子，我使用过Hudson），我正在使用带有mylyn插件的Eclipse IDE，而且项目是一个maven项目（网络）。
现在，我想通过说明以下场景来阐明我想要做的事情。分析师（A）打开一个问题（I），这是一个与maven项目（P）相关的新功能。作为开发人员（D），我收到一封关于该问题的电子邮件，我通过Eclipse中的Mylyn界面打开任务。我理解并开发与问题（I）相关的新功能。考虑一下，我是面向测试驱动开发的开发人员，因此我相应地编写了Unit，DBUnit和User-Acceptance（例如使用selenium）测试。最后，我将更改提交给源代码管理。我认为剩下的应该自动循环，但我不知道我怎么能这样做？自动循环部分如下：
源代码管理系统应该有一个后挂钩脚本，触发Continous集成工具来构建项目（P）。在构建时，应在适当的阶段运行测试代码，并生成其报告。用户验收测试应在专用服务器中执行（例如，jboss或tomcat）。此验收测试的顺序应该是在服务器上运行UA测试，然后生成UA测试报告并在服务器上运行。如果所有这些步骤都已成功完成，则执行版本控制。在版本控制部分中，maven插件或者之所以应该从问题跟踪系统中解决问题的数量，并增加相关的版本片段（次要和修订版），最后添加内部版本号。版本的片段可以保存在清单文件中，以便在用户界面中显示它。最后但并非最不重要的是，CI工具应该在测试环境中部署它。这就是我想要的所有自动循环过程。
还有一个小问题：将工件部署到生产环境应该自动或手动完成，最佳做法是什么？
任何帮助|建议将大大增加。 非常感谢你。
答案 0 :(得分：0)
让我们从侧面问题开始：在自动部署到生产时，这需要签署“业务”，即任何人。您的测试需要多长时间才能自动推向生产？他们是否足够好，你相信事情才能上线？你的停机时间是多少？那可以接受吗？如果你的测试遗漏了什么，你可以回滚吗？您是否正在监控生产，以便了解您是否引入了问题？通常，对这些问题的答案足够负面，因此无法在构建/自动测试事件的结果中自动部署。
至于跟踪，你需要一些东西。你需要你所有的假设都是真的（我怀疑它们是，但如果你到那里那就太棒了）。您还需要一个构建号，可以根据测试结果在构建时间后增加。您需要使用bug ID注释源更改。您需要构建系统来解析源更改并与问题建立关联。您需要在构建系统中使用API，以便获得与构建相关的问题数量。最后，您需要自己的脚本来执行查询并相应地更新内部版本号。