Updated: Jul 27, 2020
Written by: Jude Pineda
Our goal at Insightrix Communities is to ship software in minutes.
Minutes. Not months, not weeks, not hours. Minutes.
Earlier in our development, it took up to three months to deliver software to our clients. However, that was before we began using continuous integration (CI) and continuous deployment (CD) to deliver our software. Since making the switch to CI/CD we have increased our ability to deliver software to a production environment with speed, safety, and reliability.
This came about as a result of creating a continuous integration pipeline for our software projects, specifically with MROC (Market Research Online Community). Continuous integration and continuous deployment, or CI/CD, bridges the gaps between development and operations by enforcing automation in building, testing and deploying our applications. Implementing continuous integration and continuous deployment offers many benefits, not only to our development work but also to our clients. CI/CD offers small, non-disruptive changes, high-velocity development, and prompt responses to client feedback.
What is a CI Pipeline?
A continuous integration pipeline describes a series of automated tasks that the continuous integration server runs on any code change submitted. Our pipeline starts by installing a fresh, clean copy of our MROC software. If installation of the updated MROC software has any errors, the pipeline stops production and sends a report for review. This detection of unknown errors allows the developer to go back to the code, review the report and fix any errors in order for the updated installation to go through.
Once installation is complete, the unit tests that we have created are run on the code. We do not test just the code change itself, but the entire software code. The CI pipeline does this for every change submitted, no matter how small. Any errors encountered from running the tests are reported back to the developer for correction.
Finally, the pipeline runs a code coverage assessment. This is a percentage number which tells us what percentage of the code has been tested. We strive to make this number as high as we can, and any changes that introduce a decrease in code coverage are reviewed up close.
All of these tasks seem to be repetitive and daunting if you were to do them manually for each code change, but with continuous integration all of these processes are automated and all we have to do is wait for the code to "go through the pipeline". Once the code change passes all stages, we are assured that it is properly tested and ready to be deployed!
Small, Non-Disruptive Changes
CI relies on the concept of the minimum viable change. Since we have an automated pipeline that runs an entire suite of tests for every code change, we develop features and bug fixes that are as minimal as possible to avoid unnecessary debugging in case our CI pipeline fails. This opens up a lot of further benefits for our team. These include:
Fault isolation becomes simpler and quicker.
Mean time to resolution (MTTR) is shorter because of the smaller code changes and quicker fault isolation.
Testability improves due to smaller, specific changes. These smaller changes allow us to obtain more accurate positive and negative tests.
Our elapsed time to detect and correct production escapes is shorter with a faster rate of release.
Our backlog of non-critical defects is lower because defects are often fixed before other feature pressures arise.
Our product improves rapidly through fast feature introduction and fast turn-around on feature changes.
Our upgrades introduce smaller units of change and are less disruptive to the user experience.
One benefit of having CI/CD is the velocity with which we develop features. Due to implementing the minimum viable change, and to the robustness of the stages in our CI pipeline, we are able to push features to production quickly and with as few complications as possible.
Our product feature velocity is high. The high velocity improves the time spent investigating and patching defects.
We can introduce critical changes during non-critical (regional) hours. This non-critical hour change introduction limits the potential impact of a deployment problem.
Our release cycles are shorter with targeted releases and this blocks fewer features that aren’t ready for release.
Maintaining velocity in our development work also gives us more time to listen to customer feedback and provide bug fixes and feature requests.
Our end-user involvement and feedback during continuous development leads to usability improvements. We can add new requirements based on customer’s needs on a daily basis.
Continuous integration and continuous deployment is just one of the many new software processes that we use at Insightrix Communities to deliver robust, quality software. We continuously make tests for our software code to make sure that all possible inputs are considered, and if anything doesn't sit right, be it from the CI pipeline or from our code reviews, we can quickly go back to the drawing board and make it better. Ever since we implemented CI/CD, we have gone from a release every three months to a release roughly every week.
But, can we ship to production in minutes?
We definitely can, and we are excited to get there.