Flow

2017-02-11

Almost a decade ago we switched from svn to git. Initially we kept our workflow the same (trunk-release based)

We use a lot of external services, and one thing we really wanted was to keep features from going live, when the feature depended on something the other party has not taken live yet.

We toyed with the idea of having feature toggles, but that was mighty complicated in our codebase… and templating, annotating, aspecting feature toggles was just a journey we didn’t want to take our devs on.

So since our workflow was wired in jira, we liked kanban and groovy…

We created a ‘merge just in time’ (sounds like midget) flow something like an automated feature branch flow.

• every build a groovy script would look (execute a simple jira filter) at a kanban board find the jiras to be included in the build
  • we had 3 stages in our workflow:
    • integration-testing
    • functional-testing
    • user-acceptance-testing
• it would find the corresponding branches in git (if they exist)
• do a git merge --no-commit --no-ff and at the same time generate release-Notes html file
  • (the release-Notes are kind of important since we don’t tag all the merges)
• run the actual build (java and javascript in our case) and unit tests
• package it all up for deployment

This section will be about the implementation, issues, possible plans for the mjit flow