3

I'm kind of new into the world of continuous integration.

Because i want to practice CI/CD properly i try to read about the best practices but it is quite of a puzzle to me.

I wonder if someone with experience could let me know as of today what is the state of the practice with respect to the following matter:

"Feature branch / branch by feature" and CI.

By this i mean that i found that the part in which people are struggling the most is actually about:

The practice of CI that requires frequent integration (in mainline) and the development practice that encourage feature driven development.

From what i red there is a tension between falling in feature isolation and integrating feature even if not finished.

Hence i would like to know, what is the state of that matter today.

I saw things like branch by abstraction and feature toggles, but also other solution that are not clear to me yet but who seem to relies on tools to manage some automatic merge, that first merge and test the branch, and merging it back in the main line.

Sounds like tool like Teamcity and Bomboo have support for that. Less clear on jenkins grounds.

Hence if one could help map out the state of the art for that specific issue i would appreciate

MaatDeamon
  • 9,532
  • 9
  • 60
  • 127
  • 1
    Beside separating features into branches, I see more and more (semi-)automatic code reviews. It is basically an automated build after code is pushed to check if it breaks tests etc.. Gerrit is a commonly used OpenSource tool (Gerrit uses Jenkins in a lot of cases). But there are also other tools and services. – volker Jan 27 '15 at 16:35

1 Answers1

3

Mandatory disclosure: I'm the CTO and Co-founder of Bitrise, a CI/CD service (mainly) for mobile app developers.

What we usually recommend (and the practice what we use for in house app development) is to test every single code push, no matter which branch. Always try to push code which works / passes unit tests and of course write unit tests.

In most CI/CD services you can define a general test build which will be performed for every code push and a separate build configuration/process for deployment. You should have a base test build configuration which will test every code push and you should try to achieve a green build no matter which branch you work on.

A couple of CI/CD services offer pull-request testing without actually merging the pull-request, so that when you check the pull-request you can be sure that after the merge the tests will still pass. It's quite complicated though (the master branch's state can change even while you're reading the pull-request) and for this our team doesn't rely on these tests but simply do the merge and if it fails we fix it right away.

For a development setup like this you need at least two main branches and you always work on a feature branch. The two main branches are:

  • a development master branch: this is the branch the developers use to create new feature branches. In gitflow it's typically called develop.
  • a stable / production branch: this branch contains only stable, tested code, merged only from the development master branch and only if it's green/passing all the tests. In gitflow this branch is called master.

This branching strategy works well with most of the CI/CD services and is a good choice for mobile apps and SaaS services where you can and want to release frequently (at least for your testers / staging servers).

Viktor Benei
  • 3,447
  • 2
  • 28
  • 37