与问题控制系统集成的自动化软件版本控制
在阅读 http://semver.org/ 上的语义版本控制后，我决定使用以下模式。然而，在自动化和集成 SDLC 工具方面，我有一些未解决的问题。
Version Pattern:
major.minor.revision.build
这样；
主要：重大变更，应手动增加。
次要：次要更改，每当问题跟踪系统中解决新功能或现有功能的增强时，应自动增加。
修订：不影响次要更改的更改应在问题跟踪系统中解决错误时自动增加。
假设开发人员永远不会提交源代码，除非问题已在问题跟踪系统中得到解决，并且在此配置中问题跟踪系统是 JIRA。这意味着除了任务之外，默认情况下还有错误、改进和新功能作为问题类型。
此外，我在这个配置中添加了一个持续集成工具，并假设它是bamboo（顺便说一句，我以前从未使用过bamboo，我使用的是Hudson），并且我正在使用带有mylyn插件的Eclipse IDE，并且该项目是Maven 项目（网络）。
现在，我想通过说明以下场景来阐明我想要做什么。分析师 (A) 打开一个问题 (I)，这是一个新功能，与 Maven 项目 (P) 相关。作为开发人员 (D)，我收到一封有关该问题的电子邮件，并通过 Eclipse 中的 Mylyn 界面打开该任务。我了解并开发了与问题 (I) 相关的新功能。考虑一下，我是一个面向测试驱动开发的开发人员，因此我相应地编写了 Unit、DBUnit 和用户接受（例如使用 Selenium）测试。最后，我将更改提交到源代码管理。我认为其余的应该自动循环，但我不知道如何实现这一点？自动循环部分如下：
源代码控制系统应该有一个后挂钩脚本，可以触发持续集成工具来构建项目（P）。在构建时，应在适当的阶段运行测试代码并生成报告。用户验收测试应在专用服务器（例如，jboss 或 Tomcat）中执行。此验收测试的顺序应该是，启动服务器，运行 UA 测试，然后生成 UA 测试报告并关闭服务器。如果所有这些步骤均已成功完成，则应执行版本控制。在版本控制部分，Maven 插件或者其他什么应该从问题跟踪系统中获取已解决的问题数量，并增加相关的版本片段（次要版本和修订版），最后附加内部版本号。版本的片段可以保存在清单文件中，以便在用户界面中显示。最后但并非最不重要的一点是，CI 工具应该将其部署在测试环境中。这就是我想要的所有自动循环过程。
将工件部署到生产环境应该自动还是手动完成？
I decided to use the following pattern after reading semantic versioning at http://semver.org/. However, I have some unsolved issues in my mind in terms of automaticng and integrating SDLC tools.
Version Pattern:
major.minor.revision.build
Such that;
Major: major changes, should be increamented manually.
Minor: minor changes, should be increamented automatically, whenever a new feature or an enhancement to existing feature is solved in issue tracking system.
Revision: changes not affecting the minor changes, should be increamented automatically, whenever a bug is solved in issue tracking system.
Assume that developers never commit the source unless an issue has been solved in issue tracking system, and the issue tracking system is JIRA in this configuration. This means that there are bugs, improvements, and new features as issue types by default, apart from the tasks.
Furthermore, I am adding a continous integration tool in this configuration, and assume that it is bamboo (by the way, I never used bamboo before, I used Hudson), and I am using Eclipse IDE with mylyn plugin and plus the project is a Maven project (web).
Now, I want to elucidate what I want to do by illustrating following scenario. Analyst (A) opens an issue (I), which is a new feature, related to Maven project (P). As a developer (D), I receive an email about the issue, and I open the task via Mylyn interface in Eclipse. I understand and develop the new feature related to issue (I). Consider, I am a Test Driven Development oriented developer, thus I wrote the Unit, DBUnit, and User-Acceptance (for example using Selenium) tests correspondingly. Finally, I commit the changes to the source control. I think the rest should be cycled automatically but I don't know how can I achieve this? The auto-cycled part is the following:
The Source Control System should have a post-hook script that triggers the Continous integration tool to build the project (P). While building, in the proper phase the test code should be run, and their reports generated. The user-acceptance test should be performed in a dedicated server (For example, jboss, or Tomcat). The order of this acceptance test should be, up the server, run the UA test, then generate the UA test reports and down the server. If all these steps have been successfuly completed, the versioning should be performed. In versioning part, the Maven plugin, or what so ever, should take the number of issues solved from the Issue Tracking System, and increment the related version fragments (minor and revision), at last appends the build number. The fragments of the version may be saved in manifest file in order to show it in User Interface. Last but not the least, the CI tool should deploy it in Test environment. That's all auto-cycled processes I want.
The deployment of the artifact to the production environment should be done automatically or manually?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
让我们从附带问题开始：在自动部署到生产时，这需要“业务”（无论是谁）的签字。您的测试需要多好才能自动投入生产？它们是否足够好，让您相信它们可以上线？你的休息时间是多少？这是可以接受的吗？如果您的测试遗漏了某些内容，您可以回滚吗？您是否正在监控生产，以便知道是否引入了问题？一般来说，这些问题的答案足够否定，以至于您无法因构建/自动测试事件而自动部署在那里。
至于跟踪，您需要一些东西。你需要所有的假设都是正确的（我怀疑它们是正确的，但如果你做到了那就太棒了）。您还需要一个内部版本号，该内部版本号可以在构建时间之后根据测试结果递增。您需要使用 bug id 注释源代码更改。您将需要构建系统来解析源代码更改并与问题建立关联。您将需要一个 API 进入构建系统，以便您可以获得与构建相关的问题计数。最后，您将需要自己的脚本来执行查询并相应地更新内部版本号。
Let's start with the side question: On the automatic deployment to production, this requires the sign off of "the business" whomever that is. How good do your tests need to be to automatically push to production? Are they good enough that you trust things to just go live? What's your downtime? Is that acceptable? If your tests miss something, can you rollback? Are you monitoring production so you know if you've introduced problems? Generally, the answers to enough of these questions is negative enough that you can't auto-deploy there as the result of a build / autotest event.
As for the tracking, you'll need a few things. You'll need all your assumptions to be true (which I doubt they are, but if you get there that's awesome). You'll also need a build number that can be incremented after build time based on test results. You'll need source changes to be annotated with bug ids. You'll need the build system to parse the source changes and make associations with issues. You'll need an API into the build system so you can get the count of issues associated with the build. Finally you'll need your own bit of scripting to do the query and update the build number accordingly.