DevOps, Continuous Delivery, Continuous Integration, ... are booming, driven by the dynamic of Docker and the many open source solutions like Ansible, Puppet. But what good is all this? ...
"Continuous Delivery" ?
DevOps approach is based on the fact that the software development and production side, operational, are intertwined, and that they should therefore be managed together, and from the beginning of a project. Following this approach DevOps, the Continuous Delivery is a software development orientation of delivering regularly and automatically. This direction comes from the leaders of the web - Google, Amazon, ... - who have a strong need to deliver continuous improvements in their services on the internet.
Of course, this is not so recent that wanting to deliver its developments iteratively. As part of an agile methodology, we must deliver such a regular basis after each sprint. However, firstly the time-to-market current needs require a new rhythm, much higher, requiring industrialization and process automation. As Google, Facebook, Amazon, Twitter and others put into production several times a week, or even several times a day! Furthermore, compared to conventional agile methodology, it is not only in test deliveries, but delivery in production, including data, without impact, regression or incident!
How does it work?
First, it is essential to establish a PIC (Platform for Continuous Integration) that helps ensure software quality continuously. The subject is very well covered by the open source solutions like Jenkins, Git or SVN as well for the management of sources, and it is essential to ensure good code coverage via automated testing, but this is a subject that we can detail another time.
I will focus on the underlying technical solutions to the DevOps movement, to integrate the production in development, and development in production. The Continuous Delivery involves the creation of environments iso from development to production, and also in the opposite direction, incorporating the updated production constraints to development. For this, the open source tools flourish and complement each other : Docker, Ansible and Panamax but Puppet, Chef ...
Docker, first, allows to create containers based on LXC, which can ship the desired software. One of revolutions made by Docker is the ability to install anything, and deploy it to any environment with a lightweight virtualization, and therefore high performance. To be more specific, the first revolution has LXC himself, and Docker will provide all handling LXC container, which is not nothing. However, there is not only Docker, and similar solutions are based on a virtualization with isolation, which can have its interest in some cases. Vagrant be mentioned that relies on VirtualBox.
Container management can become subtle when several containers must work together, guaranteeing the integrity of the production operation during deployments, Panamax provides management of complex containers. Even this is not the only solution of its kind, and especially that Panamax is still young and has yet to prove itself.
Ansible, then, lets you configure its component-based environments and deploy them in target environments from development to production. Open source solution, already used by several major Internet players, its positioning is "Ansible is the best way to manages Docker". Undeniably carried by the wave Docker, though it remains consistent in a non dockerised environment.
With a different technical approach, Puppet also allows to manage configurations and deploy solutions to different environments. As Chief, relatively similar. The two have for them a greater maturity (2-3 years anyway, an eternity today!), Already more widely available to developers or sysadmin, and advanced features on the management of human deployment, answering the associated security issues.
An unaddressed items by these solutions concerns the database, its structure and its data, its change in time and its compatibility version with different environments. This is currently supported by application software and not by the tools DevOps, at least for now.
All these solutions are distributed under open source license. Some additional features are in the enterprise versions, but the main is there, freely modifiable and distributable. Even ThoughtWorks which made its success on the proprietary solution Go has moved to open source, probably in response to the rise of all other open source tools. The future will tell if this late open source conversion comes at point, or is too late, as I think.
Anyway, everyone can see that the open source ecosystem is still bringing innovation, with an impressive emulation, knowing how to make work together the various stakeholders and communities, including competitors, by pooling their work, while ensuring wide and quick dissemination, well beyond the software distribution channel owners.
And for my team?
ok, you'll say that all these tools and approach seems excellent, but how do I implement Continuous Delivery solutions in my development teams, and especially how to choose?
The answer is simple, call Smile !