We have already discussed the benefits of deploying from packages rather than from a tag, branch or binary. One of the benefits is the support for packages from infrastructure automation tools (e.g. Chef, Puppet, Ansible etc.).
What! Use infrastructure automation for app deployment? Yes, why not? Many teams are already doing so. Granted, some of these tools were created to address the problem of configuration drift. But they can be used in orchestration mode to fit the automated application deployment use case.
How Go 13.3’s support for package materials helps this
For example, one of the ways to use Chef/Puppet in orchestration mode is to simply use chef-solo/masterless puppet as illustrated below.
Use of infrastructure automation tools for application deployment
Here we have a very simple 3-stage build pipeline and a 2-stage deployment pipeline modeled in Go. The second pipeline deploys to a test environment and kicks off some tests. It may be triggered by the publication of a new build-package or by changes to deployment config (stored in version control). When triggered, the deployment job on the Go agent, passes along the revision of the package to be deployed via a remote orchestration call like this:
ssh user@host sudo chef-solo -c config.rb -j json-attribs.rb -l debug
where json-attribs.rb is pre-populated like this with package revision information:
ssh user@host echo '{"mypkg": $GO_PACKAGE_REPONAME_PKGNAME_LABEL}' > json-attribs.rb
Note the arrow labeled with Go 13.3. We have introduced the ability for pipelines to poll package repositories. Watch this space for an imminent announcement of release 13.3
Infrastructure Automation isn’t the same as scripting
Sure, we could achieve the above with just plain scripts but infrastructure automation tools provide a higher-level language - a DSL for dealing with infrastructure. While shell scripts are also a DSL, infrastructure automation DSL scripts are to plain scripts what a high level language like Java is to assembly. Well-written infrastructure automation is mostly declarative at the highest level, compared to plain scripts that are imperative.
By using these tools, we adopt the notion of infrastructure-as-code and take a step closer to devops as they:
- Blur boundaries between coders and deployers by describing infrastructure in the form of high level code (not ad hoc scripts).
- Can be easily orchestrated from an over-arching CD tool that provides end-to-end traceability (source and artifacts) and visibility.
- Already cater to a diverse deployment landscape - so there is no danger of landscape lock-in as in the case of many proprietary release/deployment automation tools.
- Offer reusable, community authored, peer-reviewed code that can be easily adapted to your needs.
- Encourage adoption of version control, continuous integration, modularity and reuse.