Question

Is there any way to push successfully built feature branches to another branch?

I’d like to have something like that:

Git repository (Gitorious/GitHub whatever). Branches:

• master (current project’s code)
• quality-assurance (branche where code waits for QA)
• feature-branches (many remote branches, where devs can develope their features)

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:

1. Developer pulls code from master branch.
2. Developer creates feature-branch-A.
3. Developer pushes changes to remote feature-branchA
4. TeamCity monitors feature branches
5. TeamCity triggers build and tests on each commit.
6. TeamCity pushes changes to quality-assurance branch if build was successful
7. QA team checks the code (maybe runs some other tests, integrity tests)
8. 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.

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.

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.

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.

Answer 1

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.

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.

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)

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).

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.