Feature: Environments

[ejholmes]

One thing we're toying with internally is running multiple Empire instances that schedule jobs into the same cluster. We can use this to have a "production" environment, but also have a sub environment for "canary" deployments.

Having multiple Empire environments works well, however, there are a number of potential issues:

1. With multiple Empire environments, you may have to do some manual work to ensure that emp env stays in sync.
2. Running a separate Empire instance, means a separate Empire API and dev's need to know the location for this API.

I think it would be interesting to think about what this could potentially look like if it was a first class feature inside Empire.

Currently, a "Release" within Empire basically represents a runnable package, including environment variables, for a service. It would be desirable to be able to take any release, and deploy it to an environment. Here's some psuedo UX for what this could look like:

$ emp deploy remind101/acme-inc # deploying just creates a release, but doesn't submit it.
Created release XYZ1
$ emp promote XYZ1 canary # Promote the release to the "canary" environment and do some testing
$ emp promote XYZ1 # Promote the release to the "default" environment.
$ emp set NEW_API_KEY=x1234
Created release XYZ2
$ emp promote XYZ2 canary
$ emp promote XYZ

In the above, the "canary" environment just means a separate private hosted zone (e.g. .canary instead of .empire).

The actual changes to support this within Empire internally wouldn't be very big, so it would just be mostly about UX.

I think there's also some questions around whether scaling configuration belongs in a release, since you may want to control that separately in different environments.

[phobologic]

I like it - how would that work with github deployments?