-2

在阅读了http://semver.org/上的语义版本控制后，我决定使用以下模式。但是，在自动化和集成 SDLC 工具方面，我有一些未解决的问题。

Version Pattern: 
major.minor.revision.build

这样;

Major：重大变化，应手动增加。
次要：微小的更改，应在问题跟踪系统中解决新功能或现有功能的增强时自动增加。
修订：不影响次要更改的更改，应在问题跟踪系统中解决错误时自动增加。

假设除非在问题跟踪系统中解决了问题，否则开发人员从不提交源代码，并且问题跟踪系统在此配置中为 JIRA。这意味着除了任务之外，默认情况下还有 bug、改进和新功能作为问题类型。

此外，我在此配置中添加了一个持续集成工具，并假设它是竹子（顺便说一下，我以前从未使用过竹子，我使用的是 Hudson），并且我正在使用带有 mylyn 插件的 Eclipse IDE，并且该项目是一个Maven 项目（网络）。

现在，我想通过说明以下场景来阐明我想要做什么。分析师 (A) 打开一个问题 (I)，这是一个新功能，与 Maven 项目 (P) 相关。作为开发人员 (D)，我收到一封关于该问题的电子邮件，然后我通过 Eclipse 中的 Mylyn 界面打开任务。我了解并开发了与问题 (I) 相关的新功能。考虑一下，我是一个面向测试驱动开发的开发人员，因此我相应地编写了 Unit、DBUnit 和 User-Acceptance（例如使用 Selenium）测试。最后，我将更改提交到源代码管理。我认为其余的应该自动循环，但我不知道如何实现这一点？自动循环部分如下：

源代码控制系统应该有一个钩子后脚本来触发持续集成工具来构建项目 (P)。在构建时，应在适当的阶段运行测试代码，并生成它们的报告。用户接受度测试应在专用服务器（例如 jboss 或 Tomcat）中执行。此验收测试的顺序应该是，启动服务器，运行 UA 测试，然后生成 UA 测试报告，然后关闭服务器。如果所有这些步骤都已成功完成，则应执行版本控制。在版本控制部分，Maven 插件或其他插件应该从问题跟踪系统中获取已解决问题的数量，并增加相关的版本片段（次要和修订），最后附加构建号。版本的片段可以保存在清单文件中，以便在用户界面中显示。最后但并非最不重要的一点是，CI 工具应将其部署在测试环境中。这就是我想要的所有自动循环过程。

工件到生产环境的部署应该自动还是手动完成？

4

1 回答 1

0

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.

  • That's totally doable, but is it really worth having? What's the value you attach to the numbering scheme?
于 2011-12-27T18:41:50.820 回答