Picture yourself working as a developer in a medium-sized Agile Team. Your team is frequently committing changes and merging code throughout the workday. Then, when the time comes for product delivery, you realize your server is facing a bug for an existing feature. Your clients are not satisfied despite your teammate taking every precaution to test it before it was built – what could’ve gone wrong? If you’re left wondering, it’s already too late.
Enter Continuous Integration (CI) – a Software Engineering practice that aims to reduce these mishaps by enforcing build and test automation, coupled with a healthy habit of regularly committing code in small chunks. Martin Fowler explains the basic concepts and guidelines for establishing CI in his blog. While these “classic” guidelines can work for many team settings, we at ISW have adopted a more modern “feature-based” approach to CI that works better for our humbly sized team.
“Individuals and interactions over processes and tools” – Agile Manifesto
Agile Manifesto emphasizes where we should invest our energies – in our people, who are most capable of making changes. Our team took the classical trunk-based CI and transformed it into a feature branch-based CI. As Avery Roswell mentions, more teams (including ours) are using the Branch-Based Development (BBD) approach today. The concept of BBD is quite simple – rather than using a single mainline (trunk) to merge your code into, your team maintains several feature branches (feature-1, feature-2, etc.). This makes perfect sense if your team is working on building multiple features simultaneously. The feature branches should have their own scripts that automate their building and testing during updates or a pull request.
Benefits of Continuous Integration
It has been a couple of years since the publication of my paper on Continuous Integration (co-authored by Michael Schiller). It discusses the core principles of CI, fleshed out with using NASA’s openmct project (the code) and GitLab CI/CD (the CI tool). We tried using Jenkins prior to making our decision to move forward with Bitbucket Pipelines because of our familiarity with Atlassian services. Also, there are certain perks to using a cloud-based CI server that you can’t overlook. For example, saving on costs, maintenance, etc. Regardless of which tool your team proceeds with, you are bound to make lives easier for both your team and your clients. Let’s dive into some of the business and technical benefits that CI can bring to your Agile team.
Stimulates Healthy Communication
To successfully practice CI, you should communicate effectively with your teammates, in and out of Scrums. This includes inter-departmental communication such as that between BI, DevOps, and developer (front end, back end, AI) teams, etc. For Bitbucket Pipelines, there is a Jira that will enable communication integration for your Agile team. So, whenever the CI pipeline encounters a problem with the build, a ticket is automatically issued for the problem(s).
Another aspect of CI that encourages healthy communication, is the process of creating test cases. BI team is in close proximity with clients and can better advise developers to create tests that mock user behaviours (more on tests later). Therefore, a better rapport will be built between BI and development teams.
Create Stable Builds
Thanks to the scripts your team will be writing, your code should be less prone to breaking unexpectedly. Software Testing is not a bulletproof solution to preventing your software from running into a “whoopsie”, but it is the next best thing you can employ. The types of tests you will be writing will depend hugely on what type of code repository you are addressing. But teams should emphasize creating tests that elevate confidence in their software. The higher the order of the tests being used, the greater the confidence your team can have in them. For example, a few well-written UI tests should give your team much more confidence in your software solutions than numerous unit tests.
Your team can write a near-infinite number of tests but, in a real-world setting, resources are more limited. The best approach is to create tests that pack a punch – that is, the ones that will sniff out the greatest number of bugs. For example, we try to focus on writing E2E and UI tests for Front End since that helps cover tons of business logic and also virtually simulates end-user behavior. Likewise, for the backend, that will mean creating integration tests to ensure API meets business logic. The tools selected for writing matter less, so long as your reports provide details of what part of validation went right (or wrong) during CI runs.
Deliver/Deploy with Confidence
You might have guessed this one! . If you’re doing CI right, all software builds can be delivered with high confidence since you will have automated scripts running before each code commit and upon every pull request. Be it for staging, production, or even development environments, so long as tests cover features that are being incrementally added, code stability can be guaranteed.
Problems with your build will be detected ahead of time – your business team will thank you for averting last-minute surprises - assuming you are working closely with the BI team, since developers cannot possibly predict/provide all test cases. An Agile team will greatly benefit from testing because of its close relations with clients and greater delivery speeds.
Save Time
And by that, I mean saving lots of it. Because CI recommends that building and testing are automated, they ought to be run at specific points of the development cycle/integration process. Automation removes the need for developers to manually trigger these steps every time your code is updated. Let me start by listing what the trigger-points are for these automated scripts:
- Before you commit your code
- While you push your code to remote
- When you create a pull request
Within each of these scripts, you will have configured steps to run all necessary validations (building, testing, linting, etc.) and even deploy your code – it is entirely up to you. What is interesting is that as your software scales up and you couple branch-based development with CI practice, the benefits of time saved become more apparent. Your branches should isolate most of the errors to themselves, so when you integrate them into the builds, you are spending less time fixing old problems.
Streamlined Development Process
This one’s a more low-key benefit, despite it being of utmost importance to me personally. A developer’s daily schedule involves making code changes at least once a day and in small chunks. I’ve discussed my top picks for important practices for CI in my publication. The code should be self-testing – the developer creates tests to cover domains of interest with high confidence. Generally speaking, the practice of CI has some rigidity to it and this, in essence, helps create a more uniform approach to development.
Teams that follow these general guidelines will synchronize their steps among themselves, making outcomes predictable. And we know that a good balance of predictability and velocity is an asset when it comes to software development. Combined with Agile practices, CI’s streamlining encourages communication, teamwork and provides teams with the extra time that can be utilized towards achieving their goals. Are you thinking of a morale boost? Because this is it.
Summary
Continuous Integration brings with it many benefits with very little initial overhead. So, is Continuous Integration really worth it? You bet. Not only will you be able to deliver high-quality code to clients, but your development team will also be encouraged to adopt Software Engineering best practices.
A reminder that there is no “correct way” of implementing CI, just the one which best works for your Agile team. Our team found peace using the Branch-Based CI approach and focusing on high-confidence testing. Had we more technical restrictions or greater availability of resources, things would’ve (and should’ve) headed in a different direction. So go ahead, pick a CI tool and a testing suite for your codebase – the power of Continuous Integration awaits you.
