The Shippable Blog

5 Reasons Why Organizations Fail to Adopt CI/CD

Modern companies today recognize that ensuring better quality releases that ship more frequently results in a competitive advantage if done right.  For most, this means adopting DevOps and having complete automation of their Continuous Integration and Continuous Delivery pipelines. For others, it means building cloud native apps and benefiting from all the newer tech like Docker, microservices architecture, etc. 

Regardless of the overall approach, experts agree that DevOps and CI/CD should be an integral part of your strategy. Yet, even though 73% organizations claim to have some level of DevOps processes in place, the number of organizations who do it well enough to be effective is miniscule.  There is no single reason for this, but let's look at the five common reasons why organizations fail to adopt CI/CD effectively. 

What is Continuous Integration and Deployment?

Continuous integration is a process where every code commit is immediately integrated into a common shared repository and built and tested automatically. The developer making the code change gets immediate feedback and can fix bugs easily since bugs are found immediately and can be tracked down to a specific commit.

Continuous Deployment is a process in which the code is packaged and deployed to a series of environments like Dev, Test, Beta, and ultimately to the live environment in Production. Automating the Continuous Deployment workflow involves many aspects like deployments, promotion through the series of environments with quality control, release management with approvals, etc. 

Automatically retry scripts to avoid network hiccups during CI process

Sometimes intermittent network issues happen to the best of us, and it is particularly frustrating if it happens in the middle of a software install.

Triggering a custom webhook after continuous integration

Even with the best continuous integration platform on the planet, you will still have scenarios when you want to trigger custom workflows after your CI finishes. These workflows could be very targeted and should have the ability to be customized based on whether CI passed.

Today, I am going to introduce you to a very versatile feature we added recently - the ability to add a custom webhook to your CI workflows that will be triggered after your build finishes. You can configure this trigger based on several factors, including build result, branch, etc and also include one or more parameters.  

This new feature is documented here in greater detail

Let's look at a simple example to see how this works. I have a project manishas/sample_nodejs and I want to open a GitHub issue in the repository if my build fails. I also want to customize the issue title and description to include a the project name, build number, commit message, and build URL.

Running CI on a Node.js application hosted on a private repository

In my previous blogs, I completed running a basic Continuous Integration (CI) on a Node.js app hosted on a public repository. Next, I configured a simple unit test for the Node.js app to check for errors each time I did a code commit. 

In this tutorial, I'll cover running CI for the same Node.js application, if it were hosted on a private repository. Hosting code on a private repository source control system is the common way developers/teams operate during software development. The overview of the work flow is to sign in using source control provider credentials, authorizing a one-time access to private repositories, enabling the project, configuring the shippable.ymlfile, completing a successful CI run for the Node.js app.

Configuring a unit test to check for errors on the Node.js application

In the previous tutorial, I ran a basic Continuous Integration (CI) on a Node.js application. As the next logical step, I'll configure a simple unit test to check for errors in my code. As per the guidelines of CI, my expectation is that for every code commit or pull request, this unit test runs automatically and immediately checks for errors. In this tutorial I will set up a unit test, configure the shippable.yml, and verify the unit test to complete a successful CI.