[From the Atlassian portal] Nothing makes or breaks agility quite like a team’s commitment to continuous integration (CI). This concept might seem daunting (especially if your team has yet to implement CI), but there is good news: regardless of the technologies a team uses, there is likely a continuous integration and automated testing framework that fits its codebase.
What is continuous integration?
Continuous integration is an Agile and DevOps best practice that allows for the regular integration of code changes into a repository's main branch and the testing of those changes as early and as often as possible. Ideally, developers integrate code daily, if not multiple times a day.
Benefits of continuous integration
Investing in CI results in rapid feedback on code changes. By "rapid," we mean a matter of minutes. A team relying primarily on manual testing *might* receive feedback within a couple of hours, but in reality, comprehensive test feedback often arrives a day—or even *several days*—after the code was modified. By then, further changes have already been made, and fixing bugs turns into an archaeological expedition, with developers digging through layers of code to get to the root of the problem.
This process is definitely not fast.
Protect quality with continuous builds and test automation.
How many of us have downloaded the latest source code and encountered compilation issues or a significant bug? The exact opposite of productivity!
To avoid this situation, two practices must be followed:
Continuous build: creates a project build as soon as a change is made. Ideally, the difference between each build is a single set of changes.
Test automation: programmatic software validation to ensure quality. Tests can trigger actions within the software via the user interface (which we will discuss shortly) or at the back-end service layer.
Think of these two practices like peanut butter and jelly: they taste good on their own, but they are fantastic together! Continuous integration pairs continuous builds with test automation to ensure that the quality of the codebase is also evaluated with every build.
And remember: to fully realize the benefits, a team must also have the discipline to pause development and address interruptions *immediately*. The energy a team invests in writing tests and setting up automation—and make no mistake, it is an investment—is wasted if builds are left to languish in a broken state. Protecting the investment in CI and protecting the quality of the codebase are one and the same.
To learn more about this topic, I suggest visiting the Atlassian portal
Comments are closed