CI/CD – Fail Fast and Fail First

Product Delivery? What CI/CD stands for?

At Moka, we’re doing software as a team (SaaT? Is that a thing? If not, remember me as the one who coined the term xD), so our products need to be tested for bugs to squash and errors to fix before arriving at the client or the market, and that’s what’s called product delivery. Is this particular point where CI/CD plays a major role in the quality of all processes.

CI/CD stands for Continuous Integration/Continuous Delivery, and it’s a technical and cultural process that merges automation and learning to increase the speed of product delivery.

“Fail Fast and Fail First.” The main purpose of continuous integration is to quickly find and fix errors, improve the software’s quality, and reduce validation time and new product updates.

Nowadays, it’s a common practice that developers perform remotely. Sometimes their code becomes desynchronized with the main branch of the repository, and they leave this integration step to the end of their task. This makes it harder to merge when there are too many changes or features added without considering some fixes that they may encounter between branches, creating more possible points of failure in the product.

CI/CD helps you quickly identify this hot spot or inform you if there’s a fatal error or failure in the production deployment before it happens, giving more stability to your software and allowing you the time to put out the fire before it starts.

 

How does it work?

Devs send periodic changes to the project repository using a CVS (Control Version System). Then, CI Services are called via web-hooks or some signaling interface. It gets the new code and starts running a pipeline that may include code standards checking, static analysis, clean caches, and anything you imagine you could need to check, execute or trigger.

After all these tests have passed, it’s time to call CD (Continuous Delivery, not an actual ? ) that it’s the one in charge of the deployment. This works in conjunction with CI, and it can run all in the same pipeline or have it decoupled if necessary.

When I started working at Moka, I watched and learned how the team used Jenkins for automated deploys. Fast forward a couple of months, and I was in charge of doing major research and configuring testing pipelines by using new tools, which resulted in using PhpCS and PhpMD to detect coding standards violations (standards we had to define and build rules for it) and catch some potential issues such as possible bugs, suboptimal code, overcomplicated expressions or unused parameters, methods, properties.

Nowadays, we’ve developed some custom tests using Scrapy and QAWolf to ensure our products’ quality before and after deployment.

 

Conclusion

To improve our code and product quality, we had to brew our own coffee and perform custom tests that work for us, balancing out the information we needed, the time we could destine to these tests, and identifying which were “safe errors” (HTTP 500 is not a SAFE error!) and which ones were deploy-blocking ones.

After we decided all this, we successfully built and tested our custom Jenkins pipeline 🙂

This article was originally written by Maximiliano Sosa.