The Shippable Blog

Ever since we added Continuous Delivery pipelines to Shippable, one of the most common feature requests has been around support for deployment to the open source container orchestration platform from Google: Kubernetes. And we're excited to announce that we've added this last week! We already support Amazon ECS, Google Container Engine (GKE), Joyent Triton, and Docker Cloud/Datacenter and with Kubernetes added to this list, you can now automate deployments to any major Container Service using Shippable.

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 follow along with the step by step tutorial you can fork our sample, sign in to Shippable, and set up the CI/CD workflow as described. 

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.

As you know, we released our new implementation of continuous deployment pipelines last month. While our basic documentation is up to date, we believe that learning the new pipelines is best done with quick tutorials that demonstrate the power of CD and how easy it is to get started.

We have created a sample project and sample configuration to deploy the project to a test environment,  create a release with semantic versioning, and deploy the project to production. The entire end to end scenario should take less than 30 mins to try out and while you won't learn every little trick, it will definitely make you comfortable with the configuration and how to set things up.

So read on and try it out!

Microservices are currently the hottest topic in software development. The concept is simple: Break down your application into smaller pieces that each perform a single business function and can be developed and deployed independently. These pieces, commonly called services, can then be assembled into an application using some flavor of service discovery like nginx or consul. The microservices approach is considered the architecture of choice for teams that want to build scalable platforms and efficiently and rapidly innovate on them. 

As infatuated as I am with this architecture, our journey to microservices was a long and winding road. It has finally led us to a version of the architecture that gives us the scalability and agility we require as a business. I want to share my thoughts, experiences, and lessons learned in a series of blogs around this topic so you may benefit from our experiences. Also, I would love to get your feedback or comments on our approach.

When you start moving to microservices, the first question before you write a single line of code is: How do you organize your codebase? Do you create a repository for each service, or do you create a single ‘mono repo’ for all services? The two approaches are illustrated below: