Less is more when it comes to CI quality

It’s been a while since I’ve last posted an article because I spent the past few weeks focusing on launching another new initiative. That doesn’t mean I’ve lost any passion or focus on the software side of things and want to still continue contributing to this ongoing blog as much as possible. So, with that in mind, let’s continue with my next discussion, which is around the impact on software quality that Continuous Integration (CI) brings.

For many people CI is a revelation of an idea that allows software developers to more responsive change. Allowing them to adapt to their customers’ needs/issues and post new features and fixes faster. It does come with many complications - especially testing challenges - where you run the risk of not being able to sufficiently test everything between the different updates. Something though which can be solved over time.

However, one thing I’ve learnt about testing in the CI space is that less is more. I’m not saying less testing though but rather smaller, more frequent updates. In the traditional software development world, organizations used to get stuck in lengthy development cycles which featured phases of development and testing followed by regression before everything was considered “good enough” to go live. This is obviously a lengthy process, though one which automation has sped up incredibly.

Still, even in this modern automated world, many teams will still run through a laborious sprint cycle or two that lasts two/three weeks each before they want to put things into production. This might seem like the safest option to a cautious tester, but it is actually the worst option from a quality perspective. While more time gives you more opportunities to test the truth is that the more you wait and the bigger your release gets, the more risky it gets too.

Think about it this way. You could be making several changes to a page on your website. You can either wait for that page to be completed or make iterative changes as you go along. The iterative option might sound messy and complicated, but the truth is that if something does go wrong, it’s also a lot easier to identify the issue and revert the change. The changes may disrupt customers, but if you have built the right customer relationships, they will probably welcome the small iterations and provide more feedback that you otherwise wouldn’t have gotten had you waited. This means this approach is actually less risky and better from both a quality and customer perspective. You obviously need to have a solid automated testing framework in place for both options, but you shouldn’t even be attempting CI until you’ve done this.

Embracing CI is not throwing away the need for sound testing or quality but rather embracing change and fluidity and allowing teams to take small risks with little impact than big risks with greater impact. There will always be features that perhaps need to be developed in their entirety before being pushed into production (especially for anything security or money related), but those should be done in separate project branches and be treated with the relevant care required. However that doesn’t mean that some iteration can’t be done on these either.

The modern world of embracing speed and efficiency doesn’t need to be bad for software quality. We instead should rather embrace the idea of failing fast and rather get these many lower risk changes out there and stop building to big release days.