The CI/CD and DevOps Blog

Announcing Windows, Mac OS, and CentOS BUILDS

Today, we are excited to announce support for multiple Operating Systems, including Windows, Mac OS, and CentOS. From the start, our goal at Shippable has been to provide you with a common CI and DevOps platform for all your applications, irrespective of application technology and architecture. 

Our journey started with Continuous Integration (CI) in 2013, when we debuted the first CI platform to support native Docker workflows for our customers. Last year, we added Assembly Lines to let you easily define end-to-end workflows across your DevOps tools to achieve Continuous Delivery with Application Release Automation, Release orchestration, approval gates, etc. This completed our end-to-end support for Ubuntu applications. 

As much as we like Ubuntu, most Enterprises have a mix of applications across multiple Operating Systems. We are proud to expand Shippable today with support for multiple platforms, as well as a bunch of other enhancements that will help you manage build infrastructure and create CI, CD, and DevOps workflows more easily.

Let's look at the top features launched today. In upcoming weeks, we will post detailed blogs on how to use each of these features.

Why the adoption of Kubernetes will explode in 2018

Kubernetes is an open-source orchestration engine for automating deployment, scaling, and management of containerized applications at scale. When your requires a large number of containers, you need a tool to group containers into logical units, and to track, manage and monitor them all.  Kubernetes helps you do that and is considered the de facto tool for container management.

The Kubernetes project is part of the Cloud Native Computing Foundation (CNCF) and has over 1500 contributors. It was started at Google, which still leads development efforts. 

Docker adoption is still growing exponentially and more and more companies have started using it in Production. It is important to use an orchestration platform to scale and manage your containers. Imagine a situation where you have been using Docker for a little while, and have deployed on a few different servers. Your application starts getting massive traffic, and you need to scale up fast, how will you go from 3 servers to 40 servers that you may require? And how will you decide which container should go where? How would you monitor all these containers and make sure they are restarted if they exit? This is where Kubernetes comes in. 

Setup a Container Cluster on AWS with Terraform Part 2-Provision a CLUSTER

This blog is the Part 2 in the series of blogs to provision an ECS cluster using Terraform. In Part 1 of the blog, we had completed the first step of setting up a VPC. In this blog, we will cover the remaining steps that will complete the provisioning of an ECS cluster and get a Wordpress instance running on it. 

Tutorial: CI of .NET Framework apps in Linux Containers

This blog was motivated by a great question on our support forum: "Can I use Shippable with a C# project?". My knee-jerk reaction was to tell him to wait for our imminent support for Windows containers. However, in my previous startup, we had built a cross-platform Xamarin.Forms based mobile app in C# and sheer curiosity provoked me to look at the latest state of Mono.

On-Demand Test Environments With ANSIBLE and Shippable

One of the biggest challenges to implementing an end-to-end Continuous Delivery pipeline is making sure adequate test automation is in place. However, even if you have automated across your entire Test Suite, there is a second challenge: How do you manage Test infrastructure and environments without breaking the bank?

If you want to move towards Continuous Delivery, you need to execute a majority of your tests for each code change in a pristine environment that is as close to your production environment as possible. This ensures that code defects are identified immediately and every code change is therefore 'shippable'. However, creating these environments and updating them with each new application version or every time the config changes adds a lot of overhead. If you're testing an application with many tiers or microservices, the complexity increases since each tier might need to be tested indepedently in its own environment against specific versions of other tiers.