Branching to the Mainline

To many Mendix Business Engineers branching must be a new concept since it was introduced only the other day. Under the hood though, we find a well known piece of technology familiar to people who have used some flavor of revision control before. Subversion.

In short, it helps engineers develop on their own timelines in parallel with other engineers, and allows you to go back in time when your application was in different state. Its no time machine, but its just as exciting.

If you have encountered the practice of branching and merging, you will undoubtably know that there is no magical unicorns nor silver bullet solutions when it comes to how you approach your branch/merge strategy. It depends on the composition of your team and state of the tasks at hand. There is no one size fits all, only guiding principles. Perfection is impossible, but we strive for it nontheless.

Branching

At our current client, we use a very disciplined yet agile strategy for branching. Its a combination of 1 branch per User Story, a QA branch, and a Sprint branch since we follow Scrum practices. It helps with selective rollouts in relatively short sprints. Thats alot of branches, and before you think “Great Scott!” we don’t treat it as a rule that covers all instances. Its a guideline, although conventional wisdom dictates that one stay as close to the mainline as possible. In reality Business often decides what goes into production after UAT, since they have the habit of changing course in mid flight. When this happens its harder to dissect your changes in the model from other changes, the longer time goes by.

Always begin with the end in mind. Deciding on when to branch is during sprint planning 2. The technical nature of our user stories help dictate our delivery strategy. This ceremony is where discipline and mindfulness should be exercised. In our experience, when the tyres hit the road, working with the modeler takes least of our time, planning takes time. Planning helps you to think about your delivery and gives you a realistic reference with which you can manage a client’s expectation when it comes to timelines.

Being busy does not always mean real work. The object of all work is production or accomplishment and to either of these ends there must be forethought, system, planning, intelligence, and honest purpose, as well as perspiration. Seeming to do is not doing. — Thomas Edison

Merging

In simple cases this should be a breeze, but in other cases to avoid time paradoxes and polluted timelines, merging should be a team effort. Together we check whether what we commit is correct and resolve potential conflicts there and then. The modeler details nicely what has changed in a way you can quickly navigate.

Merging to the QA branch helps us with our UAT and merging the User Story branches to the Sprint branch gives us a dry run for merging to the mainline later. The rule of thumb is, only quality code goes into the mainline. And finally before we release, a versioned build is created.

At the end of each sprint, we reflect and adapt and make some minor tweaks to the process. This is in no way an exhaustive description of what goes on behind the scenes, but this its the general drift.

Your needs might differ slightly or completely. What is your strategy? Drop us a comment.