My team is facing a couple of new challanges in the near future, as we will start developing a couple of (micro)services which will run in a cloud environment. Therefore we want to establish a continuous delivery workflow (and maybe move on to continuous deployment someday).
Currently we are developing an application based on Eclipse RCP together with some web applications (Java servlets). After we provide the released artifacts, the customer is responsible for operation. We release 3-4 times a year with additional maintenance releases when needed. We use git with a trunk-based (all-on-master) workflow and additional maintenance branches. The developers commit at least once a day, which triggers a build on our CI server. The master may get unstable once in a while and contains a lot of incomplete (and not hidden!) features.
As we will be responsible for operation of our services, our main goal is a always release-ready mainline in order to react fast if something is broken.Thus we thought about extending our git workflow with feature branches. But we soon dropped that idea because of several reasons (e.g. merge conflicts with features/stories that take 1-2 weeks, no satisfying CI feedback, etc.)[1-2]. Hence we decided to keep our all-on-master workflow (without maintenance branches) and work with patterns like feature-toggles, branch-by-abstraction, etc. [3-4]. However, we don’t have much experience with those patterns and also think that it’s non trivial to always keep the mainline 100% clean and release-ready. Thus we decided to have an additional development branch which is merged back when needed or at least at the end of a sprint. This ensures that the master branch really stays release-ready, while the development branch don’t has to be (but of course should be).
After this workflow has established, we want to move a bit further and introduce some kind of short living feature branches. In my opinion the main problems with feature branches arise from their rather long life time. Imagine you have a user story which is composed of several subtasks. A task takes about 1 day of work. When the task is done, the changes get pushed to the mainline which triggers a full build on the build server. This is CI as we know it, right? However, my commit can still lead to an unstable mainline. Of course I can run all unit tests locally for example, but the build server might run additional tests or check other quality metrics which I don’t want to run locally. Thus it would be nice to have a dedicated branch and build job for my task. This enables me to verify and check my changes before I push them to the mainline. So I grab a subtask to work on, and automatically get a feature branch and build job. When the task is finished it gets pushed to the mainline and the branch+build job is cleaned up.
I know this workflow is similar to 'gitflow' for example, however the main difference is the lifetime of branches as mentioned above.
What do you think about this workflow? Which workflows do you use?
(1) „Continuous Delivery“, Jez Humble and David Farley, (2) martinfowler.com, FeatureBranch, (3) martinfowler.com, FeatureToggle, (4) martinfowler.com, BranchByAbstraction,
