Introducing WunderFlowJanne Koponen
Mon, 06/01/2015 - 09:30

Most of the established git workflows are tailored around single product or project. They do work well before the project is published or when the release process is handled inhouse. But for established sites with ongoing improvements when all the new features need to be shown to customer and accepted by them they caused more problems for us than they solved.

Ok, so let's get started, here is how it works:

Base branches:

In WunderFlow we have three main branches each having their own distinct purpose.

Production branch is always the branch that holds the version of code that is deployed to production. This is the branch also used as base for hotfix branches.

At any time master branch should contain only working, tested and release ready code from new features. Any new feature should be branched from this branch. This branch should also be used for any automated testing or any other quality assurance processes. New releases are made from here by merging this branch to production (and possibly tagging the release). Any hotfixes made to production branch should be rebased here as soon as they are released. Those two branches are quite in par with the git-flow so basically so far our flow can be used as a drop in replacement for it.

Our first big difference here is the development branch. First of all it is the safe playground for experimental code, testing and debugging. Anything can be committed here, but nothing living only in this branch will ever end up in production as this branch will never be merged upstream. Instead this branch can be at any time be reset to master discarding any wild code residing only in here. Secondly sometimes there are projects that have for example such integrations that can't be reliably tested in local / test environments. This is handy when you need to test new features relying on those integrations, or you need to debug some issues with them with current production code & data. Finally this gives you a nice environment to display your current progress or sandbox features to the customer. There are great solutions like platform.sh or Pantheon that give you working environment per branch, but with customers this is usually not convenient for them. They prefer having single environment they can easily remember (e.g test.theirdomain.tld) and bookmark. This way they can also have an environment where they can input testing content to test new features without having to input that content to multiple environments just to test different features. This also helps with the integrations mentioned earlier.

Another "new" feature in our workflow is the concept of epic branches. Often while developing bigger stories they need to be broken into many smaller features usually depending on each other. The case might be that the whole story need to be released at once, or it can be that there are some features that can be put into production earlier. Our epic branches are the tool to manage such situations. In essence epic branch is just a temporary branch that functions as a master branch for certain set of features. Everything that applies to the base workflow applies here just by substituting master with the epic branch.

Simple example:

Let's say you have a user story about a new content type that needs to be added to the site. There should also be new view listing the content of that type. You have next release coming in 2 days and it's not sure if you can finish the whole story by then. The customer also wishes that they should be able to start inputting the new content as soon as possible, even if it wouldn't still be possible to display that content in any listing. You also already have some new features waiting for the release. Clearly a case for epic branch.

So, you create a new epic branch for the new content type and listing, let's call it epic/NewContent. Then you start working on the new content type creating a feature branch from the epic branch: feature/NewContentType.

After getting everything ready you can push that branch to epic and that in turn to develop so that customer can review it and comment if there is need to add or change anything.

While you wait for customer to review that work you can now create another feature branch from epic to start working on that listing view: feature/NewContentList. In time that can also be merged to epic and ends up to develop for review.

Now during the remaining time before the release there are different scenarios that can happen:

1. New content type is not accepted by the customer. So nothing from this story end up in the release.

2. Customer accepts the content type and wants to include it into the release so they can start inputting content while they wait for the listing feature to be finalized. You just merge the feature/NewContentType branch to master and do your release.

3. Both the content type and listing features are accepted by the customer. You can merge the epic/NewContent to master and do your release.

As it's always hard to estimate how long developing something can take and also how fast you can get review feedback for your work you need to be prepared for different situations. With WunderFlow it's easy to be prepared for those different scenarios. As this was just a simple example but imagine there being more of those similar stories, some smaller features and couple of hotfixes happening at the same time: you'd still have the same options of choosing easily what goes to the next release with clearly separated features and the possibility to work on new features depending on other features.

Most up to date definition of WunderFlow can always be found at http://wunderkraut.github.io/WunderFlow/

Drupal Planet

158