Reliable Continuous Delivery with Cloudsoft AMP Blueprints
One of the questions we at Cloudsoft are often asked is “how do I use blueprints in CI/CD?”
Well, we don’t know. We don’t know your environments or goals or constraints and those all matter. There are many, many ways blueprints are useful in a continuous delivery pipeline, because they give way for all the stakeholders and their tools to share a common language. From architecting, through dev/test on localhost or with containers, to deploying and promoting, to the actual dynamic runtime models, Cloudsoft AMP gives way for everyone to have a clear and authoritative description of your applications.
Pictures are worth a thousand words, though, so this post looks at some of the ways we internally develop and run our systems using AMP.
The AMP QA Framework is a cornerstone of our deployment pipeline: this is a powerful set of components that allow organizations to implement a systematic approach to testing applications. It supports the automatic testing of blueprints, the storage of test results, and viewing of those results.
It is rare to see a pipeline that is not specific to the organization implementing it, but whether you’re using GoCD, Concourse, Drone, Jenkins, and/or hand-rolled web hooks and scripts, the Cloudsoft AMP models, API and CLI, and the Cloudsoft QA Framework, are all designed to plug fluidly into the tools and organizations that need them.
Dealing with Complex, Fluid Landscapes
First, let’s consider why you would need this capability. In this cloud-first IT era, your landscape is complex and always in motion. Changes frequently occur across any/all of these integral components — and are not always in your control:
- Applications
- Blueprints
- Clouds
- AMP
Testing these comprehensively for one application can be tricky — now consider doing that at scale for your organization. In summary, testing comprehensively, regularly and on-change can be expensive and error prone if you do not have a joined-up, everything-as-code approach to your applications, their tests and their deployment/management.
Having a deployment pipeline that allows you to deploy your applications to Production often and with minimal risk is essential.
Assuming you appreciate the benefits that AMP provides in deploying and providing continual in-life management of your applications, let’s take a step back and consider the question, “what is a good approach to developing, testing and running application blueprints in Production?”
Development and testing is not a singular activity — it should take place many times in your workflow. The diagram below illustrates where, in this iterative approach, AMP and the QA Framework fit in relation to your Source Code Management (SCM) and Continuous Integration/Continuous Delivery (CI/CD) tools.
Figure 1: The develop-test cycle (click to enlarge).
In this case, they are GitHub and Jenkins respectively. However, these can be substituted to meet your requirements. The AMP QA Framework is sufficiently flexible to fit into your pipeline — it has been purposely designed to be so.
By running AMP and some compute nodes in Docker containers, you can speed up your develop-test cycle in Phase 1 (shown in Figure 1 above). Using existing compute nodes can save a lot of time as there is no provisioning required each time you deploy. But if you do need to have a “clean” location, a new container can be created very quickly.
The AMP Blueprint Composer (shown in Figure 2 below) assists your blueprint development. The Graphical Designer helps you quickly see and use the available entities, locations, policies etc — and the configuration options available for each. This is a great way of establishing the “shape” of your blueprint.
The YAML Editor allows you to then quickly add the detail (both are synchronized).
Figure 2: AMP Blueprint Composer (click to enlarge).
You can then deploy the blueprint to your Docker container to quickly test the behavior — and refine your blueprint. You can also, if you wish, deploy to the cloud to test behavior that cannot be tested in a local container.
Once you are happy, you are now ready to commit the changes and open a Pull Request (PR) in GitHub — doing so will automatically kick off Phase two (shown in Figure 1) to test your application, blueprint, AMP and clouds.
https://www.youtube.com/watch?v=GNLsIdUe2xM&feature=youtu.be
Once Phase 2 completes successfully and your PR is merged, testing will run on the master branch (Phase 3 — shown in Figure 1) to ensure your changes are compatible with the work of your fellow engineers.
Deploying to Production is the final phase — and as a result of the previous phases, it should be a low-friction, low-risk activity that you can do often.
Hopefully, this has illustrated a useful developer workflow and demonstrated how the QA Framework is a valuable element in a deployment pipeline.
Cloudsoft and Docker are sponsors of The New Stack.
Feature image by Robert Lukeman via Unsplash.
