What Do We Harvest by Adopting CI/CD? – InApps 2022

Armory has been collecting input for a larger, more in-depth study on the return on investment (ROI) of continuous delivery and wanted to shine the spotlight on this first piece in the series, not only for Ashima Purohit’s insights, but also to celebrate International Women’s Month. The larger paper will be published within the next month.

In recent years, more and more companies are adopting continuous integration and continuous delivery in their product development process. The trillion-dollar mistake is miscategorizing software development as a production problem, in the sense of being able to scale it up to be able to produce things more reliably.

Some of the fundamentals and non-negotiables I strongly believe in from over 15 years in engineering and development are around continuous learning and improvement to get to market faster without compromising quality. CI/CD is an enabler to achieve this. Adopting continuous integration and continuous delivery is an essential practice to be completely agile.

With multiple developers committing code multiple times a day, chances of a broken build increase, requiring time and effort spent backtracking, identifying and fixing it. The longer the delay, the more time and effort incurred.

I would like to emphasize here that CI does not help remove issues, but it helps you identify them early in the cycle, and that’s the real ROI, where every check-in is verified in an automated build.

One of the best practices I always practiced as a developer and fostered is maintaining robust CI and CD pipelines. If the integration fails, the broken build becomes the highest priority to fix. System quality, not just velocity, is critical for a sustainable and scalable development model.

It sounds like just three simple steps: push, test and fix. But despite this simplicity, CI might become challenging if only a few members of the team practice it. Consequently, CI requires a change in culture and support from management.

To gain successful team adoption of CI/CD and to achieve its ROI, it’s vital to understand that the automated build relies on code compilation, the first test that is followed by a suite of tests.

Remember that CI’s purpose is to provide feedback as soon as possible. If a developer must wait an hour to get feedback, it won’t work. That’s where the team might prefer to go back and use long feature branches. Hence a good balance of unit testing and integration testing is essential to keep the CI loop smaller. Automated delivery pipelines guarantee fewer errors. In case they occur, errors can be detected quickly. Team members will spend less time fighting fires and can focus more on engineering work. This helps reduce toil and add value sooner, safer and with happier workers.

Using reliable tests is another important aspect. I have recommended to my teams that for every critical or blocker issue spotted in production, create a test case and include it in the CI loop.

Building the CI/CD pipeline is not a fire-and-forget exercise, nor is there a cookie-cutter way to get it right. It takes an iterative approach to build the desired CI/CD pipeline with a seamless software delivery process. To configure and layout the right strategy for a custom CI/CD pipeline involves analyzing the data like the frequency of commits, size of commits, build frequency and test cycles. Typically, there are three stages during the development cycle that have proven to help determine the continuous integration strategy: commit and build, automated testing and deployment. Let’s delve into those.

Commit and Build: At Freshworks, our developers branch out from a local working copy. Once finished making changes and undergoing code review, they commit their code to a shared repository that will integrate their snippet with the central codebase. The CI pipeline can detect the change and trigger a build right from extracting the code. It will run a unit test, summarizing the report as a successful or failed build. The report will include details like unit test coverage, series of last committed files, build summary — success or failure — and a notification distribution list and method (email/slack/IM/SMS). CI plays an essential role in streamlining this process by automating each step after the code is written.

Automated Testing: Once the build is successful, it’s essential to test the entire system in environments similar to the production environment. As I have emphasized earlier, spending time to identify the right set of smoke, sanity and integration tests will pay off to ensure quality checks within acceptable CI cycle times.

Deployment: In the final stage, the built piece of software is rolled out into production. Identifying the rollout environments and setting up ahead of time always have helped my teams. We have the dev environment, rolling into the QA environment, pre-prod/staging environment and finally prod. The dev environment sees multiple builds triggered in a day. There is a daily scheduled deployment from dev to QA, then a scheduled as well as on-demand deployment to staging. CD requires this process to be automated, which ensures a reliable delivery to users from pre-staging to the prod rollouts.

Putting in all those efforts are worthwhile when you reap the benefits of a continuous development process by transitioning from ad-hoc/manual to the automated and configured CD pipeline in terms of:

• Faster release cycles and better business advantage: Speeding up the build and deploy cycle will increase speed to market.
• Reduced risk and higher-quality products: The ultimate goal of a continuous delivery process is to make each release a painless experience for both the QA teams and customers. By releasing features continuously, the risk of bugs ending up in production is drastically reduced.
• Lower costs: Adopting a continuous development model eliminates many of the fixed costs incurred in building and testing changes to the application. For example, automated environment provisioning will reduce the costs associated with maintaining several testbeds and test infrastructure. Parallel testing will cut down on the number of machines required for testing. By continuously committing the code, the team spends less time, and therefore money, on fixing bugs.
• Better business advantage: Moving to a continuous development model gives teams the flexibility to make changes on the go to meet new market trends and user needs. Application monitoring tools are a great way to find and fix failures while also logging the problems to notice trends faster. It also aids in understanding the feedback we receive from customers to ensure our products meet rapidly changing demands.

Adopting CI/CD is setting the stage for success.

Image provided by sponsor.