What is CI?

In 1999, a talented engineer named Kent Beck wrote a book called Extreme Programming Explained, which has greatly influenced how software development and deployment look today.

The key concept of his methodology is fast feedback and continuity. You don’t lock yourself in a basement for a year to create the perfect program for your customers. By the time you’re done, there’s a good chance your competitors will have already eaten you alive by rolling out a rough, feature-light prototype that they continuously improved. Essentially, the methodology reflects the core reality of modern business: change quickly with the environment, or fall behind.

Today, we’re going to talk about one of the most critical elements of this approach — Continuous Integration (CI).

In the real world, where business needs can change every month, developing a competitive app often looks like this:

“Imagine you’ve been asked to finish building a lab on an island that another foreman started. You show up at the site, and instead of a completed building, you find a giant fan the size of a house, a huge balloon, and a room stuffed with brooms. Scratching your head, you clear out the junk and finish the lab. You hand it over to the scientists, but five minutes later they come running out, screaming, ‘TOXIC GAS LEAK!!!’

— How the heck did this happen! It should be working! — you yell in despair and call the previous foreman:

— James, we’ve got a toxic gas leak! What’s the problem?

— I don’t know, it should’ve worked. Did you change anything?

— Not much, just moved the brooms…

— The brooms were holding up the ceiling!

— What??? What, excuse me???

— I said, the brooms were holding up the ceiling. There were gas tanks above them. Really heavy ones, so I had to stuff the room with brooms to support it.

— You could’ve at least put a note on the door saying the brooms were holding up the ceiling! We’ve got toxic gas leaking! What do we do?

— Turn on the fan. It’ll blow the gas off the island.

— I dismantled the fan as soon as I got here!

— Why?

— Why did you even build a 120-ton fan? Couldn’t you have just left a box of damn gas masks? — Gas masks? That would’ve taken forever to find. I already had the fan left over from a previous job.

— James, I got rid of your fan! We’re suffocating here!

— So what are you even doing there? Get on the balloon and get out!”

A product can be built and rebuilt by dozens of different people. Documentation is either partially missing or doesn’t reflect reality. Every new engineer tries to wade through tangled chunks of code, hoping to fix the bug that’s bothering the customers. Often, this breaks something else entirely. When the business asks for new features to outpace competitors, the developers are just praying they don’t break something that was already working.

Unfortunately, all projects make sense only at the very beginning and only to the people who wrote them. After a few years, they turn into black boxes full of technical debt, too expensive to rewrite properly from scratch. The cost of each change grows exponentially as the project gets more complex. While you can’t avoid this entirely, you can make it much easier by implementing CI as early as possible.

Continuous Integration is a software development practice that ensures a continuous process of delivering improvements in small, simple increments. The opposite of this is months-long release planning, where you fix hundreds of bugs and add tons of new features in one go. Then, as soon as the release goes live, the whole thing comes crashing down, requiring emergency hotfixes just to get it working in a production environment.

With CI, defects and errors are caught at the earliest stages, not during the final release. This is made possible through automation, which handles:

• pulling the source code from the repository;
• building the project;
• running tests;
• deploying the finished product;
• sending out reports.

The key advantage of CI is the automation of testing. I’ve encountered plenty of projects that were rewritten so many times they became nearly unreadable:

• The code became harder and harder to understand. Every new change required engineers to spend more time figuring out the logic.
• Fixing one bug often broke something that had previously worked.
• Each new engineer wrote in their own style, which made the code even less readable. Internal coding guidelines existed, but they were rarely followed.
• The code often had obvious errors, but didn’t break only because of some side effects.

In general, this is completely normal. People get tired. People won’t manually check every three-line change across fifty complex tests. We’re simply not built for monotonous, repetitive work that requires constant focus.

These kinds of problems are perfectly solved by automatic control and testing in a unified CI pipeline.
You wrote some code but ignored PEP8 standards on indentation, spaces, or variable naming? Automated linters will check it and flag any issues before your code is merged into the main branch.

Discovered a critical vulnerability in one of the hundreds of packages in your project? You’ll get a full report of the issue with links to the specific CVEs and recommendations on how to fix them. Vulnerable code won’t make it into the main branch or to your clients.

One of the developers added a secret password directly into the code? A new feature breaks one of the hundreds of already functioning ones? All of this gets detected automatically every time any change, no matter how small, is added. With CI, you can be sure that the application you deliver to your clients will always meet at least the minimum standards you’ve defined in the CI pipeline.

Disadvantages:

The main downside is that you need a DevOps expert who understands your business needs and can set up the whole process. This specialist needs to understand both developers and the product managers responsible for the business. If you have that, you can build an automated system that ensures the required quality without burdening developers with unnecessary tasks.
And if you need help setting up Continuous Integration from scratch or within an existing project, we’re always happy to help. Reach out to us at WiseOps, and our experienced DevOps team will take care of your business.