4

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.

Simon
  • 2,329
  • 4
  • 30
  • 49

2 Answers2

2

Seems like a valid scenario.

Update: Since TeamCity 8.1 there is a dedicated Automatic Merge feature.

Older reply: TeamCity does not have bundled support for merging/pushing branches automatically (for number 6 in the above list). There is a related feature request in the TeamCity issue tracker.

To get the scenario working in current TeamCity versions, you can have a separate build configuration in TeamCity with snapshot dependency and trigger on success which will grab the feature branch (done by TeamCity) and the build script will then run merge and push git commands. You will need to use TeamCity agent-side checkout to be able to do that.

Yaegor
  • 1,771
  • 9
  • 12
  • Probably you can note that this feature was already implemented in TeamCity 8.1: http://blog.jetbrains.com/teamcity/2013/10/automatic-merge/ – KIR Jun 24 '14 at 11:47
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.

Community
  • 1
  • 1
Sam Holder
  • 32,535
  • 13
  • 101
  • 181
  • I've already read your solution and according to it configured TeamCity. It was a PoC just to show how it all could looks like, but right now I'll setup it for production. Thx for sharing a great post. Instead of github I'd like to use Atlassian Stash (small team). Don't know if I'll switch to Girious, we will see. GitHub isn't an option. it's also pity that TeamCity requires two build configs, because we can run out of free cnfigurations quickly, but as I said, we will see how it all works. Thx one more time. – Simon Jan 12 '13 at 15:41