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. 

Continuously deploy your app from GitHub to Amazon ECS

Amazon provides a hosted Container Service for Docker called EC2 Container Service (ECS) as part of its container focused suite of services. Many of our customers seem to love the ECR (EC2 Container Registry) and ECS combination to store and run their applications. Amazon ECS can be accessed by going to your AWS Management Console, selecting EC2 Container Service from the list of Services. 

In part I of this series, I demonstrated a simple scenario where we built and pushed a Docker image to ECR as part of the CI build workflow. In this blog post, I will show how you can set up deployment of the same sample application into Amazon ECS, In the last part of this series, I'll show how you can complete your Continuous Delivery pipeline with deployment into subsequent environments, promotion workflows between environments, and release management.

If you want to see an extended version of this scenario in action, attend our webinar in February by signing up below:

Sign up!

Pushing your Docker image to Amazon ECR after CI

Amazon provides a hosted private registry for Docker images called EC2 Container Registry (ECR) as part of its container focused suite of services. Many of our customers seem to love the ECR and ECS (EC2 Container Service) combination to store and run their applications. Amazon ECR can be accessed by going to your AWS Management Console, selecting EC2 Container Service, and clicking on Repositories in the left sidebar. 

In this blog post, I will go through a simple scenario with a sample project where we enable a project for CI, build a docker image as part of the workflow, test the image, and then push it to Amazon ECR. In the next blog, we will then set up the rest of the Continuous Delivery pipeline for the sample application.

Continuous Delivery using JFrog Artifactory with Shippable

We recently added a native integration with JFrog's Artifactory. You can push your versioned package to Artifactory after CI as explained in my previous blog. From Artifactory, you can deploy the package to a Test environment, and then promote the package through various environments and finally to production. You can also pull dependencies from Artifactory as part of your CI/CD workflows on Shippable.

JFrog's Artifactory is one of the most advaced repository managers available today. It is open source and especially popular with Java app developers and also Enterprises that want to self host a repository manager for their projects.You can learn more about Artifactory here.

This blog continues from where the earlier blog Pushing to JFrog Artifactory after CI left off. So it assumes that you have forked the sample project, set up CI, and pushed HelloWorld.war to your Artifactory account. This blog will deploy the WAR file to a beta environment running on a node cluster on Digital Ocean.

Pushing to JFrog Artifactory after CI

We recently added  a native integration with JFrog's popular artifact repository, Artifactory. You can now add your JFrog credentials to your Shippable account and then perform the following actions as part of your CI/CD workflow:

  • Pull dependencies from Artifactory
  • Push files, versioned packages, or artifacts to Artifactory
  • Trigger your continuous delivery pipelines if a file/package stored in your Artifactory account changes

JFrog's Artifactory is one of the most advaced repository managers available today. It is open source and especially popular with Java app developers and also Enterprises that want to self host a repository manager for their projects.You can learn more about Artifactory here.

Let us see how this works with a sample project which builds the sample code and creates a .war file which is then pushed to Artifactory. Follow the step by step directions below to set up CI for the project and push to Artifactory.