TeamCity推送功能分支到主分支 [英] TeamCity push feature branches to master branch
问题描述
有没有办法将成功建立的功能分支推送到另一个分支？
Is there any way to push successfully built feature branches to another branch?
我想有类似的东西：
Git仓库（Gitorious / GitHub无论如何）。分支：
Git repository (Gitorious/GitHub whatever). Branches:
- master（当前项目代码）
- quality-assurance QA）
- 功能分支（许多远程分支，开发人员可以开发其功能）
开发人员应该只能读取主控和读/写他的功能分支
QA读/写质量保证分支
TeamCity - 读/写master，质量保证，只读到功能分支
Developer should have only read access to master and read/write to his feature branches QA read/write quality-assurance branch TeamCity - read/write master, quality-assurance, read only to feature-branches
现在我想要一个像这样的工作流程：
And now I would like to have a workflow like this:
- 开发人员将更改推送到远程功能branchA
- TeamCity监控功能分支
- TeamCity会在每次提交时触发构建和测试。
- TeamCity将更改推送到质量保证分支
- 质量检查小组检查代码（可能运行其他测试，完整性测试）
- 如果QA决定一切正常，到主分支。
- Developer pulls code from master branch.
- Developer creates feature-branch-A.
- Developer pushes changes to remote feature-branchA
- TeamCity monitors feature branches
- TeamCity triggers build and tests on each commit.
- TeamCity pushes changes to quality-assurance branch if build was successful
- QA team checks the code (maybe runs some other tests, integrity tests)
- If QA decides that everything is OK, they push changes to master branch.
我不知道这个步骤是否有必要，也许每个功能分支成功构建和测试后，与主人合并。
i don't know if that step with QA is necessary and maybe each feature branch after successful build and tests should be merged with master.
首先我想知道：这是否有意义？我刚刚开始CI，我不知道它是否会工作。
Firstly I would like to know: does it makes sense? I'm just starting with CI and I don't know if it will works.
其次，如果这个工作流是正确的，我想知道如何配置TeamCity
Secondly, if this workflow is correct, I would like to know how to configure TeamCity to do something like that and what if there would be some kind of conflict or where something could goes wrong.
最近我观看了关于Git + Jenkins + Gerrit的演讲，我在这里看到了类似的，但对于.NET开发，我个人更喜欢TeamCity，但是如果使用Jenkins更容易做到这一点，我会改变主意。
Recently I watched presentation about Git+Jenkins+Gerrit where I saw something similar, but for .NET development, I personally prefer TeamCity, but if it's much easier to do that with Jenkins, I change my mind.
推荐答案
我们使用github实现了一个具有相同目标的工作流程（虽然实现稍有不同），虽然它可能涉及到一些设置，确保teamcity的一些问题。我对此处的类似问题有另一个答案
We have implemented a workflow with the same goals as this using github (although the implementation is slightly different) and whilst its possible it involves a bit of setup sure to some issues with teamcity. I have another answer to a similar question here
我们的解决方案基本上涉及每个开发人员拥有自己的主存储库的分支，他们有读和写权限，并从主（绿色）存储库拉取权限。开发工作在分支（每个故事，短命），这是由团队城市建立时，他们推到他们的个人叉。
Our solution basically involves each dev having their own fork of the main repository, which they have read and write rightsa and pull rights from the main (green) repository. Devs work on branches (one per story, shortlived), which are built by team city when they push to their personal fork.
一旦开发人员准备将他们的更改合并到主数据库，他们提交一个pull请求，并审查代码，最后与他们的主分支合并。他们然后把他们的主bramnch到他们的个人叉。
Once a dev is ready to merge their changes in to the master they submit a pull request and have code reviewed then finally merge with their master branch. they then push their master bramnch to their personal fork.
如果此构建成功并且所有测试通过（此时我们也部署到azure，然后针对部署运行测试），那么主分支将推送到绿色仓库由团队城市构建代理。
If this build is successful and all tests pass (we also deploy to azure at this point, then run tests against the deployment) then the master branch is pushed to the green repository by the team city build agent.
此推送必须是快进或推送被拒绝（这解决了自动合并的任何潜在问题，这充满了恐惧）
This push must be a fast forward or the push is rejected (this solves any potential issues with automated merging, which fills me with dread)
你可以很容易地扩展它，让开发者分支推送到QA仓库，QA做提交到构建服务器，触发推送到绿色（或者QA有权推送到绿色）。
You could easily extend this to have devs branches push to QA repositories and QA do the commit to the build server which triggers the push to green (or have QA have the rights to push to green).
teamcity安装可能有些麻烦，因为您需要将快照依赖关联起来，这会禁止使用模板，并且意味着您至少需要2构建配置每个开发（我们有4处理部署到天蓝色和运行测试针对天蓝），所以如果你有很多开发人员，这可能是一个痛苦的管理。理想情况下，您不应该执行此操作，但由于团队中的问题，这些问题仍未解决如果测试失败，您不能总是使构建失败。
The teamcity setup can be a bit of a pain, as you need to chain things with snapshot dependencies, and this inhibits the ability to use templates and means you need at least 2 build configs per dev (we have 4 to deal with the deploying to azure and running tests against azure) so if you had a lot of devs this might be a pain to manage. Ideally you shouldn't need to do this but due to issues in teamcity that are still unresolved you can't always make the build fail fast if the tests fail.
这篇关于TeamCity推送功能分支到主分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
