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:

  1. 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.
  2. 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.
  3. 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:

  1. We can built and test components independently.
  2. We can deploy and version our platform as a single unit.
  3. We can reuse our provider packages elsewhere.
  4. 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!


Bart Spaans, February 4, 2018

Tweet this