Laura (@rhein_wein) and I are Docker Captains. This means we demonstrate a commitment to sharing our Docker knowledge with others. Amongst other languages, she talks Ruby and Postgres and I talk Java and Couchbase. But we talk to each other using the common language of Docker!
This multi-part interactive webinar will teach you how to build a Docker-native CI/CD pipeline using Codeship. This series will be using the application used for Docker for Java Developers workshop, which in turn uses WildFly and Couchbase.
Codeship is a Docker-native SaaS platform for creating your CI/CD pipelines. SaaS means that you don’t need to manage setting up CI/CD server and workers. It allows to existing Dockerfiles and images on any registry and enjoy full customizability for their dev environments. Learn more at Codeship Docs.
WildFly is a Java EE 7 compliant application server that allows you to build amazing web applications. A light memory footprint, a blazing fast startup and customizable runtimes makes it an ideal candidate for deploying in the Cloud. Powerful administration features, intuitive web console and REST API makes it a breeze for management.
Couchbase is an open-source NoSQL document database. It allows you to develop your applications with agility and operate at any scale. Agility comes with flexible schema, SQL-like query language, rich Web Console, REST API and CLI, a mobile-to-backend solution and much more. Unlike a master/slave architecture, Couchbase scales linearly and can be deployed on a variety of clouds and on-prem.
Lets learn the basic concepts of Codeship in this introductory webinar:
What CI/CD platform do you use for building your deployment pipelines?
Continuous Integration, Continuous Deployment, and Continuous Delivery are all related to each other, and feed into each other. Several articles have been written on these terms. This blog will attempt to explain these terms in an easy-to-understand manner.
What is Continuous Integration?
Continuous Integration (CI) is a software practice that require developers to commit their code to the main workspace, at least once, possibly several times a day. Its expected that the developers have run unit tests in their local environment before committing the source code. All developers in the team are following this methodology. The main workspace is checked out, typically after each commit, or possibly at a regular intervals, and then verified for any thing from build issues, integration testing, functional testing, performance, longevity, or any other sort of testing.
Continuous Integration
The level of testing that is performed in CI can completely vary but the key fundamentals are that multiple integrations from different developers are done through out the day. The biggest advantage of following this approach is that if there are any errors then they are identified early in the cycle, typically soon after the commit. Finding the bugs closer to commit does make them much more easier to fix. This is explained well by Martin Fowler:
Continuous Integrations doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.
There are lots of tools that provide CI capabilities. Most common ones are Jenkins from CloudBees, Travis CI, Go from ThoughtWorks, and Bamboo from Atlassian.
What is Continuous Delivery?
Continuous Delivery is the next logical step of Continuous Integration. It means that every change to the system, i.e. every commit, can be released for production at the push of a button. This means that every commit made to the workspace is a release candidate for production. This release however is still a manual process and require an explicit push of a button. This manual step may be essential because of business concerns such as slowing the rate of software deployment.
At certain times, you may even push the software to production-like environment to obtain feedback. This allows to get a fast and automated feedback on production-readiness of your software with each commit. A very high degree of automated testing is an essential part to enable Continuous Delivery.
Continuous Delivery is achieved by building Deployment Pipelines. This is best described in Continuous Delivery book by Jez Humble (@jezhumble).
A deployment pipeline is an automated implementation of your application’s build, deploy, test, and release process.
The actual implementation of the pipeline, tools used, and processes may differ but the fundamental concept of 100% automation is the key.
What is Continuous Deployment?
Continuous Deployment is often confused with Continuous Delivery. However it is the logical conclusion of Continuous Delivery where the release to production is completely automated. This means that every commit to the workspace is automatically released to production, and thus leading to several deployments of your software during a day.
Continuous Delivery is a basic pre-requisite for Continuous Deployment.
Continuous Delivery Maturity Model
Maturity Models allow a team or organization to assess its methods and process against a clearly defined benchmark. As defined in Capability Maturity Model – The term “maturity” relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.
The model explains different stages and helps teams to improve by moving from a lower stage to a higher one. Several Continuous Delivery Maturity Models are available, such as InfoQ, UrbanCode, ThoughtWorks, Bekk, and others.
Capability Maturity Model Integration (CMMI) is defined by Software Engineering Institute at Carnegie Mellon University. CMMI-Dev particularly defines model that provides guidance for applying CMMI best practices in a development organization. It defines five maturity levels:
Initial
Managed
Defined
Quantitatively Managed
Optimizing
Each of these Continuous Delivery maturity models mentioned define their own maturity levels. For example, Base, Beginner, Intermediate, Advanced, Expert are used by InfoQ. Expert is changed to Extreme for UrbanCode. ThoughtWorks uses CMMI-Dev maturity levels but does not segregate them into different areas.
Here is another attempt to the maturity model that picks the best pieces from each of those.
As a team/organization, you need to look at where do you fit in this maturity model. And once you’ve identified that, more importantly, figure how do you get to the next level. For example, if your team does not have any data management or migration strategy then you are at “Initial” level in “Data Migration”. Your goal would be to move from Initial -> Managed -> Defined -> Quantitatively Managed -> Optimizing. The progression from one level to the next is not necessarily sequential. But any changes in the organization is typically met with an inertia and so these incremental changes serve as guideline to improve.
Leave a comment on this blog to share your thoughts on the maturity model.
hip is a Docker-native SaaS platform for creating your CI/CD pipelines. SaaS means that you don’t need to manage setting up CI/CD server and workers. It allows to existing Dockerfiles and images on any registry and enjoy full customizability for their dev environments. Learn more at Codeship Docs.
WildFly is a Java EE 7 compliant application server that allows you to build amazing web applications. A light memory footprint, a blazing fast startup and customizable runtimes makes it an ideal candidate for deploying in the Cloud. Powerful administration features, intuitive web console and REST API makes it a breeze for management.
Couchbase is an open-source NoSQL document database. It allows you to develop your applications with agility and operate at any scale. Agility comes with flexible schema, SQL-like query language, rich Web Console, REST API and CLI, a mobile-to-backend solution and much more. Unlike a master/slave architecture, Couchbase scales linearly and can be deployed on a variety of clouds and on-prem.
