Publishing

Overview

Once a blueprint has been modified and thoroughly tested, it is time to publish a new version of the blueprint. Publishing a blueprint enables all the environments using the blueprint to be notified there is a new version available. Publishing does not make the blueprint available outside of your Organization - only to the environments within your organization.

As the author and publisher of a blueprint, you are encouraged to follow these versioning rules to make it easier for others to consume your blueprints. If you like to use major and minor version numbers:

1. Use a major.minor versioning scheme.

2. Any time you make a breaking change, bump the major version - for example:

   1. Changing the name of a variable.

   2. Changing a resource's behavior.

3. All other changes can bump the minor version.

If you are encouraging the use of immutable infrastructure, you may choose to use a single increasing number for each blueprint publication.

As a blueprint consumer, you can look at the delta between the version you are using and the newly published blueprint version to make your own conclusions about the changes that were made and whether they will work in your environment.

Theory of Versioning

Blueprints are versioned for the same reason software components are versioned. Infrastructure as Code (IAC) treats infrastructure definitions, such as blueprints, as versioned code. To effectively develop and distribute software components or IAC, well-tested known quantities are periodically labeled and released for consumption. In short, infrastructure definitions are code, and need to be treated like code:

• Develop

• Test

• Release