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:
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.