How Continuous Integration Plays a Crucial Role In Business Agility

There Was a Lot of Hype About Business Agility

Unfortunately, Agility in business became one of the most hackneyed topics in IT. The main message was "Agility is Cool," and makes business flexible, reducing time to market. It's true. Why then do I raise this subject once again? Well, to show practical aspects and explain why continuous integration plays such an important role.

Business Agility Meaning

An Agile business is a business that is capable of reacting to a new environment and making changes quickly.

Businesses that have better agility automatically have a significant advantage when compared to competitors. Whoever exposes a new feature first wins. Let's review the survey of delivering some features in production and its stages.

Reviewing Steps Required To Deploy New Change in Production

Depending on system complexity, developers have to take several steps to merge final changes and deploy them to production. Obviously, for big companies, it takes much more than for startups. Let's review the most classical steps (almost mandatory for both small and big projects):

1. Implement the feature and write tests for it (assume as one step).
2. Verify changes in the pre-production environment (also known as UAT or PRE PROD).
3. Create PR and obtain approvals.
4. Deploy to production.

Analyzing Technical Steps Behind the Scene

Not all mentioned steps can be part of CI (well, not technical CI). Let's review the technical steps behind the implementation process of each step, and describe how costly it is in a matter of time. If we review, we might see the next stages:

It looks a bit complicated. There are basically 4 branches:

Development Stage (Localhost) Environment

At this stage, developers implement new features, write tests, etc. It is a fundamental stage where developers spend most of their time.  

Deployment to User Acceptance Stage (UAT, Also Known as Pre-Production)

At this point, changes can be shown to the tester/analyst/product owner or even to the business. This often occurs before deployment features have been tested with heavy tests like regression/UI/performance.

Deployment to Production (Feature Is Completed)

At this stage, the feature is completed, and businesses can finally use it to make a profit.

Calculating Time Required To Deliver Feature

Now let's roughly calculate the time required to deliver a feature.

Among all stages, we review 3 main areas: Deploy to Localhost/UAT/Production. I roughly estimated them with brackets with N ∈ (1,100), M ∈ (1,10) and K ∈ (1-5).  Number values are not that critical, but the closer we come to production, the fewer executions we do, which means:

Calculating Total Time Considering All Steps 

These numbers remind us that even small steps can be called many times, and thus, have to be considered in the same way as slow steps.

Small Change Request Estimation

Assume that in such case, the developer will deploy to localhost 10 times, deploy to UAT 2 times, and one final run to production:

Therefore the results are almost 2 days (17.4h) in total from localhost deployment to production. These are pretty heavy steps: UI tests, Regression, PR review.

Average Change Request Estimation

Now let's calculate a more realistic example when a developer needs to rebuild their project 30 times, and after pushing his changes in UAT, he got bounced 5 feedbacks. At the end of development, he deployed changes in production, but found a critical bug and had to redeploy new changes again.

In this case, the results say that about ~ 8 days (44h) are required. It might look scary, but in reality, it makes it even moreso.  

Reviewing How CI Affects Business

We reviewed how each small step in development can bring visible delays in development. Now, let's review how it might affect the business. Let's assume we have 3 companies: Startup, Agile Bank and Conservative Bank with outdated slow CI:

This image shows that even having just a better CI business can conquer a big part of markets due to early feature releases. In this example, I showed that a startup eats 50% of the market in 3 weeks and only 10% of the market rests for Conservative Bank. The numbers are pretty artificial, but explain how a comparatively small difference in CI might give a huge boost for business.

Improving CI Recommendations

There is no silver bullet that can make any CI perfect, but there is a set of known problems that brings the most slowness. In general, all problematic steps can be split in two groups: quick steps, but frequently used, and just slow steps. Both of them eat a lot of time in total.

Use Better Hardware

The easiest way to reduce CI time is to use better hardware: better CPU, more RAM, better SSD.

Improve Build Time

There are couple of ways to reduce build time:

• Cache up to running build process in RAM.
• Support hot-swap changes; e.g., JRebel (for JVM languages).

Use Local Cached Repository For All Dependencies

In order to reduce the time for fetching dependencies, use internal repositories and caches.

Run Test in Multithreading (Especially for UI and Regression Tests)

The best way to increase time spent on tests is to run them together in parallel. Obviously, test design has to support it.

Keep More Environments

One of the known problems that block developers is not having enough environments to push changes. Having more environment instances lets developers test their changes without blockers.

Code Review Practices

This step depends on policies and team players' behavior, but you still can:

• Discuss implementation with colleagues before you start.
• Split tasks into reasonably small parts.
• Keep a policy that does not allow ignoring other developers' Push Requests.

Conclusion

I hope in this article I've explained that CI might look like part of a process that plays an extremely important part in the development delivery and business. When I design new pipelines, I never underestimate their importance and apply a lot of effort to try to save every second.