针对一个由12位开发人员组成的团队,请问您能够帮助我确定一种建立和部署产品的流程和工作流吗?我们使用Mercurial进行源代码管理,并使用TeamCity作为构建服务器。我们有一个跟踪问题和增强请求的系统,其中大多数是由一名开发人员在一天或两天到一周的时间内处理的相当小的错误和改进。我的目标是让业务部门和IT管理层协商决定开发人员可以处理哪些问题。完成后,这些更改将被提交并推送到中央代码库,并在问题跟踪系统中标记为“已完成(dev complete)”状态。然后,QA和业务团队应该能够从已标记为“已完成(dev complete)”的问题中选择,并根据优先级、所需QA量和QA资源可用性将其包含在我们的产品中,以供下一版本发布时使用。
原本我打算通过让开发人员在每个问题(ticket)上创建一个新的命名分支(branch),来实现此功能。这样,每个被选中的问题的分支(branch)可以合并(default)并构建和部署到QA(最终生产环境)。
但问题在于持续集成(Continuous Integration,CI)。我认为我只能静态地配置TeamCity以从我们中央代码库的特定分支(branch)上构建。也许这是我们使用的TeamCity版本的限制。目前我们使用的是5.0.3版本,但可以升级(version upgrade)。也许有一些巧妙的方法可以使其构建并基于提交触发构建的分支(branch)的头(top)而非特定分支(branch)?如果开发人员在不同的分支(branch)上提交和推送所有内容,并且这些分支(branch)直到一段时间之后才合并(default),直到QA需要等待这些更改构建出来并且如果有破坏性(build broken)的构建成本会更高,那么我们就没有一个特定的分支(branch)可以进行持续集成构建。
也许我正在把这件事情复杂化或者忽略了一些简单的东西。希望得到您的帮助。是否有一种方法可以实现选择性集成(Selective integration)以进行发布,并在开发人员提交(push)时仍然进行持续集成(CI)呢?
原本我打算通过让开发人员在每个问题(ticket)上创建一个新的命名分支(branch),来实现此功能。这样,每个被选中的问题的分支(branch)可以合并(default)并构建和部署到QA(最终生产环境)。
但问题在于持续集成(Continuous Integration,CI)。我认为我只能静态地配置TeamCity以从我们中央代码库的特定分支(branch)上构建。也许这是我们使用的TeamCity版本的限制。目前我们使用的是5.0.3版本,但可以升级(version upgrade)。也许有一些巧妙的方法可以使其构建并基于提交触发构建的分支(branch)的头(top)而非特定分支(branch)?如果开发人员在不同的分支(branch)上提交和推送所有内容,并且这些分支(branch)直到一段时间之后才合并(default),直到QA需要等待这些更改构建出来并且如果有破坏性(build broken)的构建成本会更高,那么我们就没有一个特定的分支(branch)可以进行持续集成构建。
也许我正在把这件事情复杂化或者忽略了一些简单的东西。希望得到您的帮助。是否有一种方法可以实现选择性集成(Selective integration)以进行发布,并在开发人员提交(push)时仍然进行持续集成(CI)呢?