Mike Last

Mike Last

Always keen to learn, absorb and apply new technologies, principles and practices.

Continuous Integration @ IDBS

3 minute read

Originally this was to be a quick post highlighting that IDBS engineering is moving to trunk-based development, but it occurred to me, as a new member of the team, that I should also cover my personal integration into IDBS.

About my joining experience

I joined IDBS as a software architect in April, bringing with me 23 years’ experience working within the financial services industry, albeit within the same large company. As I am sure you can imagine, leaving a safe and secure role was both exciting and nerve-racking, in equal measure. After all, it has been a while since I was ‘the new guy’.

I should not have been concerned though, the onboarding process has been managed excellently, despite the current Covid lockdown. Personally, I have found everyone to be friendly, inclusive and willing to make time for my endless questions. IDBS feels like a warm and welcoming family, underpinned by the professional processes provided by its parent company, Danaher.

As an advocate of many modern practices, including continuous integration and continuous delivery, I was really pleased to hear that the feature teams are focused on continuous integration, with trunk-based development being an obvious candidate.

My experience of source-control branching models

Over the years I have witnessed several source-control branching models and they can essentially be classified by the length of time it takes a single commit to be integrated with all existing code (continuous integration). This tends to be proportional to the quantity and lifespan of branches.

In the past the branching model was often chosen based on the perceived risk protection that long running branches are thought to provide. Sadly, without the teams diligently applying thorough and regular merging strategies, long running branches represent the greatest risk. In fact, outside of IDBS, I once witnessed a year’s worth of development binned when the long running branch could not be merged back, the source-control branching model in question was based on a branch per project.

Adoption of trunk-based development

Currently the teams at IDBS predominantly use Gitflow, this limits the lifespan of branches to feature development and relies on the teams following best practices to ensure regular merging across feature developments.

Already underway is the move to trunk-based development, this further reduces the lifespan of branches to a maximum of two days. Removing the need for regular merging strategies across features as all commits to trunk are merged immediately. The small but frequent nature of such merges reduces their complexity and allows them to be managed by the originating commits author.

Don’t break the build

One of the main objectives of trunk-based development is to maintain a trunk (mainline or master branch) that is always releasable. This fits well with the company’s aspirations for continuous delivery and agility, but as you can imagine, provides some challenges given the frequency of change:

  • Not every new feature or change can be implemented within one or two days - Thankfully there are several design patterns that can assist, predominantly Feature Flags.
  • Each change to trunk should be tested pre-commit - The frequency of such commits requires focused test automation at multiple levels, ideally taking maximum advantage of focused unit and integration tests.
  • Each change to trunk should be peer reviewed pre-commit - There are several ways to achieve this, including, pair programming, mob programming and pull request workflows.
  • Static Code Analysis - Performance, reliability, security, and style can all be measured to some extent using static code analysis tooling pre-commit.
  • Building code pre-commit - Fast builds are required to support the frequency of change.
  • Deployment - To support parallel run time testing and dynamic analysis, pre-commit deployments to ephemeral environments are beneficial.

Despite all those measures the build may break for all sort of reasons. That’s OK, that’s why it exists. What matters then is speed of response. Revert or roll forward as appropriate and learn from it!

For anyone considering adopting trunk-based development, I highly recommend exploring https://trunkbaseddevelopment.com