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.
Escape provides a few different ways to compose packages into bigger platforms:
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.
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.
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: [email protected] provides: - postgres outputs: - postgres_url deploy: deploy.sh
And suppose we also have an application that consumes a
id: my-project/my-application version: [email protected] 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: [email protected] 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: [email protected] 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
id: my-project/my-platform version: [email protected] 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!