Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
When setting up a continous integration environment, does it always entail having the build server pull code and merge between branches?
Or is it something you NEVER want to do because you are depending on an automatic merge would usually ends up having issues (and requires manual intervention).
I've never seen a CI system doing any merging. In theory you could set it up to do that but as you mentioned the build will break if you run into any merge issues.
CI environments usually have a specific fixed branch as the "build" branch and the CI server will monitor that branch for new check-ins to fire off a new build cycle.
CircleCI, my hosted CI service can be set up to do this. Circle automatically builds all branches by default. For our own code, green builds on master are automatically merged into the production branch. Of course, only do this if you have a good test suite.
Now, that case is easy, because nobody pushes to production directly.
I think there's a lot of interesting work that can go on here. Eventually, I'd like to get all bugfix branches to auto-merge into master on green. I've been in situations where I'm working on a bug, run all the tests, then discover I need to merge with master (rather than fast-foward), and forget to run all the tests again, and end up breaking the build.
A feature I'm interested in writing is comments in the commit message that say "merge with branch X, if it's green". That way, it's never possible to have master be broken.
The other responses here don't make a lot of sense to me. Your CI system doesn't have to be dumb. It should be able to gracefully handle merge conflicts, by not merging, and informing the user. And on any "shared" branch, like master or production, merges should always be fast forwards!
Never do that. Automatic merge is just one reason. Even more importantly, you should be able to commit to your branch until you've finished, without fear of breaking the trunk.
However, if you're using a tool like Jenkins, you might want to add a separate automated build for your branch, so that you continue to get fast feedback on commits.
Automated merge between branches? - That is simply not a good idea.
CI is a great process and needs to be setup for comparatively big projects. However, I would never trust to automated merging. Because, it is quit common to get wrongly merged files resulting in compilation error or even worth by unintended change in coding logic.
I haven't heard about any CI system that would automatically merge branches. Why? Because it is not always that easy, and even if you're using one of the most sophisticated DVCSes available out-there it is still possible that a human is required to review the code that has been changed. It is especially tricky when people have actually changed bits in the same file (i.e. same method in the class, same function).
I think automatic merging would do more harm than good. And in the end you (as a developer) don't want to waste your time on investigating issues that are not real issues, and happened just due to the fact that a piece of code was not as smart as you are, and couldn't figure out what the code after merging should look like.
Most of the answers here point out the problems of automated merging. However, we used it successfully to merge from our production branch into our test branch (hot fixes and such would automatically merge downward). And also from our test branch into our development branch (fixes to problems discovered during testing would automatically merge downward). In our case, all automated merges went away from production, giving us opportunity to review and test any merge consequences before we pushed code into production.
I'd like to say the process was perfect, but our CI system would silently fail (not perform the merge) if merge conflicts required human intervention. It would have been much better for the system to send notifications so the development team would know that merges were failing.
Merging always needs to be done manually. If you design the software and manage the development with a degree of sanity, then conflicts will arise only on very, very rare occasions, but when they do occur, they need a human to ensure that the merged result makes sense.
To get the benefit of continuous integration, developers need to merge changes and check their work into a central repo/branch on a frequent basis (every hour or so).
