Co-ordinating deployments when using ember-cli-deploy-lightning

1

When using ember-cli-deploy-lightning-pack, is there a way to automate activating the right version of the Ember app.

For example:

Scenario 1:

There are some updates to the Ember app. These updates are compatible with the version of the Rails app. So the ember app gets auto deployed and activated via CI without deploying the Rails app.

Scenario 2:

There are some updates to the Ember app. These updates are incompatible with the version of the Rails app. The Rails and Ember app need to go live together. This could perhaps be done manually by a dev, but I’m looking for a way to automate this.

Scenario 3:

There are some updates to the Rails app. These updates are incompatible with the current version of the Ember app. The Rails app needs to activate the right version of the Ember app during its deployment.

Are there any Ember CLI deploy plugins or popular techniques to manage these kind of deployment scenarios.

Any pointers would be much appreciated.

2

The general solution I would strongly advocate is to have an API versioning scheme and to make your API changes backward compatible.

My EmberConf 2015 presentation (available on YouTube) explains why making your Rails and Ember app “go live together” is a fiction. TL;DR single-page apps have user sessions usually measured in the minutes involving multiple API calls.

3

I see. Correct me if I’m wrong. The point of this is to be able to deploy Ember apps independently of the Rails backend. To do that, the Rails backend must support multiple versions of the Ember app running at the same time via API versioning. The other benefit of this is that sessions of users on an older version of a Ember app does not get disrupted (+ a zero downtime deploy). Is that right?

Thanks.

4

Your understanding is correct.

5

I think Scenario 2 is still is a problem where the CI auto deploys & activates a new version of the Ember app which uses a new version of the Rails API. So I suppose the CI just needs a check of sorts to not activate the new version if the API hasn’t been deployed yet. And then for the API’s CI to activate that version.

I’m not sure if thats how folks are setting things up.