Escape is a new open source release engineering tool that helps you split up your software and infrastructure into small components. Today we’re going to have a look at how the new version of Escape makes it even easier to combine those components back together into cohesive units of their own. Oh what!
To read more about what Escape is and how it works please see the announcement blog post or the documentation. If you just want to get through this blog post then here, use this tl;dr: Escape can be used to build self-contained packages that build, test, deploy and operate applications, cloud infrastructure, containers, documentation, images, etc. It wraps your favourite tools and handles all the book-keeping needed to get your software into production.
Platform releases
Escape provides a few different ways to compose packages into bigger platforms:
- Dependencies
A package can depend on a number of other packages. Versions are resolved and stored at build time. This provides a strong coupling between packages. - Providers/Consumers
A package can define an interface, which other packages can consume at deployment time. This provides a looser coupling than dependencies and can be used to abstract away layers or services. - Extensions
A package can extend another package, inheriting all its dependencies, consumers, build and deployment jobs, etc. This can be used to reuse deployment and build patterns.
So what’s new?
The biggest difference with previous versions of Escape is the ability to compose all these different types of packages back into one cohesive unit using a wrapper release.
Suppose we have one package that deploys a Postgres database somewhere and
suppose that it exposes a postgres provider so that other deployments can
find its configuration:
id: my-project/postgres-provider
version: 1.0.@
provides:
- postgres
outputs:
- postgres_url
deploy: deploy.sh
And suppose we also have an application that consumes a postgres provider:
id: my-project/my-application
version: 1.0.@
consumes:
- postgres
inputs:
- id: postgres_url
default: $postgres.outputs.postgres_url
deploy: deploy.sh
The provider needs to be present before the consumer can be deployed so usually
we would need to deploy the postgres provider before we deploy the
application; as two separate steps.
However, in the new version of Escape we can now write a wrapper package to combine and configure dependencies in a parent release. Meaning we can deploy our whole stack in a single step again!
id: my-project/my-platform
version: 1.0.@
depends:
- release_id: my-project/postgres-provider-latest as postgres
- release_id: my-project/my-application-latest
consumes:
postgres: $postgres.deployment
Dependencies are deployed from top to bottom and Escape now allows you to reference a dependency as the provider for the ones that follow it.
There are a few advantages to doing things like this:
- We can built and test components independently.
- We can deploy and version our platform as a single unit.
- We can reuse our provider packages elsewhere.
- We can get back a closer coupling between providers and consumers; which can be handy if you know exactly what implementation you want to provide.
What else is new?
Depending multiple times on the same package
As part of this change it’s now possible to reference the same dependency multiple times, as long as all of them have been assigned a unique variable:
id: my-project/my-platform
version: 1.0.@
depends:
- release_id: my-project/postgres-provider-latest as postgres
- release_id: my-project/postgres-provider-latest as postgres-for-other-service
- release_id: my-project/my-application-latest
consumes:
postgres: $postgres.deployment
- release_id: my-project/my-other-application-latest
consumes:
postgres: $postgres-for-other-service.deployment
Depending multiple times on the same provider
The same is now true for the consumes field:
id: my-project/my-platform
version: 1.0.@
consumes:
- postgres as p1
- postgres as p2
depends:
- release_id: my-project/my-application-latest
consumes:
postgres: $p1.deployment
Check it out!
You can check out Escape on Github or dive straight into the Documentation and Quickstart. We also have some cool stuff in the pipeline, if we say so ourselves and if you can excuse the pun, so don’t hesitate to follow us on Twitter! —> Don’t hesitate!