CI/CD series - Plutora: best practices for continuous code

This is a guest post for the Computer Weekly Developer Network in our Continuous Integration (CI) & Continuous Delivery (CD) series.

This contribution is written by Jeff Keyes, director of product marketing at Plutora — the company is known for its technology which works to capture, visualise and analyse critical indicators of speed and quality of software delivery.

Keyes writes…

CI/CD done right will build high quality software faster, as it’s one of the foundational parts of DevOps. To ‘do’ DevOps, teams need to focus on decomposing the applications as well as integrating automated checks as much as possible. Which in essence focuses on building quality in, instead of inspecting the quality after the code is built.

By putting in checks to verify the quality throughout the process, you’re doing it closer to when the code was actually written, meaning there is a more frequent feedback loop between the developer and what is taking place. Therefore, best practice of continuous integration is for the developer to be the one that not only writes the code, but also writes the tests for the code to ensure it works effectively.

For this to be successful, these tests need to be run quite frequently. By frequently running the automated tests, fewer bugs slip through to follow on phases of testing. By using CI/CD practices instead of traditional methods, the IT team will overall end up with higher quality code once it’s done.

Taking this a step further, when there are individual teams coming together and collaborating on this, the code that they integrate together is also of higher quality. This is because the quality of the individual sub-systems and component are of higher quality and the team can focus on ensuring the quality of the integration points.

Buggy bugs

It can be difficult when an IT team is faced with trying to find a bug and they are not sure whether it’s in their own code, someone else’s code, or in the touchpoint between the code. These automated tests help focus from where the core problems originate.

This enables the team to take the next step of integrating the code lines more frequently. This is the foundation of Continuous Integration. Continuously integrating code lines closes the feedback loop between the teams. So when the IT team puts it all together, there is a reduced risk of any errors due to multiple bugs being present.

In traditional software development pipelines, another common point of failure is getting the built software onto preproduction and production environments. Automation of the deployment is an integral part of CI/CD pipelines.

Automation ensures consistency and speed and it means that the IT team can regularly deliver code together with minimal effort. Defects in the process are addressed in a permanent fashion. The Continuous Deployment portion of CI/CD again raises the overall quality of the applications being developed.

So when CI/CD is implemented correctly, it can lead to a higher quality code being produced. But while it can facilitate this, in reality it depends on what it is used for, and how individual teams work together to ensure that when the code is brought together, they are sharing the best version of it.

Data Center
Data Management