Our goal is to make the continuous delivery of containers simple and effective.
OverviewContainers have simplified the delivery of application and content. Historically the process of repeatable deployment and configuration of applications has been a hard and expensive problem. Containers packaging up an application and its dependencies into a common image that is easy to build, easy to run and very importantly easy to distribute updates. This allows the focus to move on the delivery process rather than deployment details.
PipelinesA pipeline is made up of a set of related stages. Code enters at one end and moves through the pipeline based executed tests, approvals and events. The purpose of the pipeline is to establish a repeatable process to taking code changes, testing those changes and deploying good changes into production or staging environments. This is similar to the idea of “every time I check in a change, I should run unit tests and automatically build the application”, we just want to take the notion a step further to also run automated functional and system tests and ultimately deploy a change to production. Almost every software project has some form of a Pipeline and the goal is to have the Pipeline fully automated and reliable. At IBM we believe this is a critical piece of the Application Lifecycle that should be simple yet powerfully integrated with services that are available to the modern application. There are two videos below:
- Introduction and overview
- How to setup a local development environment and pipeline
Demo and introduction to Continuous Delivery for Containers
How to setup a Pipeline on Bluemix DevOps ServicesUpdate: The steps in the video below to get enabled for the Containers Beta are no longer necessary. Also you can now quickly create a project and pipeline from our examples by using the ‘Deploy to Bluemix’ button from any of the sample projects on GitHub.
What is Bluemix DevOps ServicesBluemix DevOps Services provides developer services for IBM Bluemix. Using Bluemix DevOps Services you can host your application code in a GIT repository, or link to an existing GitHub repository. Bluemix DevOps Services provides ‘Tracking and Planning’ to create stories, tasks, and defects to describe and track project work, and use agile planning tools for the product backlog, releases, and sprints. For those familiar with Rational Team Concert, Bluemix DevOps Services Tracking and Planning provides similar capabilities with a modern user interface that makes tracking and planning an enjoyable part of the development process. Bluemix DevOps Services also includes the Delivery Pipeline for the delivery of applications to Bluemix. The pipeline triggers from changes to the application code, and provides continuous build and delivery stages for the IBM Container Service. For example:
Deployment strategies and ‘The Twelve Factor Application’The process of updating an application varies from application to application. Typically the process either follows an upgrade strategy, or a rolling deployment strategy. An upgrade takes an existing application and infrastructure and applies updates to the software running within that same environment. A rolling-deployment stands up a new instance of the application, attaches external services and data-sources and then re-routes traffic to the new instance, or not, based upon metrics and goals. Generally speaking traditional on-premise application fall into the upgrade scenario, and cloud-centric applications into a rolling deployment. It is important to understand the characteristics of your application and which scenario is best suited to manage it. The Twelve-Factor App does an excellent job of summarizing attributes of a cloud-centric application that is well suited towards running in a container, and continuous delivery. These attributes are valuable for horizontal scaling, feature flag work, high availability and they also impact how we manage our application. We will look at how to manage upgrade strategies and rolling deployment strategies separately.
Rolling deployment solution summaryA typical process for a rolling deployment might be:
- Version n of your application is deployed and has traffic being routed to it
- Application is modified, packaged and tested through a continuous integration process
- New version of the application is deployed
- Some portion of traffic is routed to the application for Canary Testing, Feature Flags, or red-black deployments
- Based on metrics, or testing traffic flow is increased or decreased to the application versions.