0

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

git worlkflow 1

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.

extended git workflow

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,

  • 3
    "What do you think about this ...?" and "Which ... do you use?" are not good types of questions to ask here. Can you improve your question to make it more specific? – scriptin Apr 15 '15 at 7:02
1

If I understand your question correctly, the only reason you want a "clean master" at all times is so that you can "react fast if something is broken". I believe this is best served by doing hotfixes on release branches, rather than moving all non-hotfix tasks to non-master branches.

Basically, you do all development work on master as usual, then when the sprint ends and you do a release, you "cut" a branch from master and call it something like "releases/20150411". Then, if you ever find a bug on production, you figure out which release branches are affected by it, apply a patch to those release branches, then rerelease/redeploy/etc the patched versions to the users that had the broken releases. This is actually more flexible than the "clean master" approach since you can easily have multiple release branches, which (assuming you have several deployment stages like we do) minimizes the risk of accidentally adding new bugs/features to the "farthest out" user group as a side effect of fixing the current bug.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.