Templatizing Delivery, The Future of CI / CD
Because homegrown is a thing of the past.
Jenkins. Bamboo. Artifactory.
Nexus. Gradle. Maven. Ansible.
We all know these well known names in the field of Continuous Integration / Continuous Deployment (CI / CD).
Right?
Exactly.
More and more we see large enterprises and small startups moving away from homegrown solutions. They are beginning to converge on a standard set of tools and solutions, commercial and open source, that can be brought together to support the basic paradigm of a developer’s code checkin.
These deployments can be to cloud (public, private or hybrid) or on-prem, in an appliance running in a customer’s data center, or in some unique cases, it is a combination of two or three of these target environments.
Enterprises do not want to build these capabilities in-house, as the expenses can be prohibitive to stand up dedicated infrastructure and tools engineers who will develop and operate these solutions over and above the product DevOps activities that they already have to staff up for.
This hyperconvergence of toolset is reflected in Netflix’s recent release of Spinnaker to the open source community.
Spinnaker sits a layer above the toolset, integrating them to provide a standard, seamless way to deploy code changes into target environments in the cloud.
Excitement is at an all time high as Tools and DevOps engineers engage to determine how best to bring Spinnaker into their environments.
Another tool that VMWare has been promoting is their vRealize Code Stream product, which is a commercial offering that is tightly integrated with VMWare vCloud capabilities.
The market is nevertheless still young in terms of a standard, scalable, and secure CI / CD model. “DevOps as a product” has yet to be realized in the industry today.
Opportunities still very much exist to build on top of what companies like Netflix have done to provide even further capabilities to the industry.
Most importantly, there is an ongoing shift to embrace the “pipeline as code” mentality, as one can see with fantastic DSL tools such as the Jenkins Pipeline (formerly Workflow) plugin and Jenkins Job Builder from OpenStack.
When your entire workflow can be defined as highly readable code, you can make updates to it directly in your Git repository; these changes will immediately be reflected in your production pipeline.
You can deploy a fully functional pipeline from code with a single command-line operation, you can roll back, fork your pipelines, merge pipelines and a whole new world of complexity becomes simplified instantly.
Continuous delivery to an appliance, to an on-prem enterprise software installation, or private cloud in a customer’s data center can be one of the most complex operations to support.
You have to account for additional considerations around firewalls and data integrity, not to mention the customer appetite for change.
But were a problem like this to be solved in a templatized manner, the world around CI / CD pipelines would be restricted to only two kinds of providers.
The first is the hardware infrastructure group that supports the environments on which the pipelines have to run – these could be in the cloud or on-premise (e.g. IT, shadow engineering labs, AWS, Google, Rackspace, etc.).
The second is the product development team, who only have to stand up an instance of the pipeline for their product and maintain that going forward.
The hardware infrastructure group simply provides compute power and high availability SLAs.
Everything from that point is driven simply by a CI / CD template that can leverage that compute power and construct source control and artifact management servers as well as build, test and deploy environments. The template is all managed as code in a DSL (e.g. Groovy, YAML, etc.).
To get started on a new product, the product development team would leverage that CI / CD template or blueprint…
Run a command to spin it up…
Which would setup their source and artifact repositories, their orchestration server of choice (e.g. Jenkins), their build and test servers, and their target deployment models for staging, pre-production, production etc.
Effectively, such a product team could engage almost immediately with a handful of command line operations or clicks through a self-service portal that operates on this template.
You would not need to spin up a dedicated build team to operate the pipeline, but would own it fully as part of their natural build-test-deploy lifecycle.
Instead you would need to write you own product-specific build scripts, unit tests, functional tests, etc. and directly operate what you deploy into production environment(s).
However, a home-grown CI / CD pipeline with an operating team behind it becomes obsolete.
Weeks and months of effort are thereby automated into oblivion by leveraging such common CI / CD template and blueprints that are already out there, and the product teams can focus on what they do best – shipping great product.
Woo-hoo!
cPrime is partnered with the leading companies in the CI/CD space, Cloudbees Jenkins, JFrog Artifactory, SauceLabs, Docker, Puppet Labs and more.
