Tips on Ember App Deployment Process: the Netguru Way

Without it, a lot of time is wasted and we end up generating problems that would not otherwise have existed. What are the aims of every deployment process (whether Ember, Rails or anything else)? Simply - to be fast, reliable and simple.

Netguru’s Previous Ember apps deployment process

At Netguru, we’ve been developing Ember applications for a long time now. From the very beginning we decided that our deployment process would be as similar to Rails deployment as possible. For this, we used Capistrano and capistrano-ember_cli gem (developed inhouse).

The gist of our old deployment process is illustrated in the following diagram:

During deployment, Capistrano enters the server, pulls the repository, runs the ember build command and eventually copies the output to the nginx root directory. Nginx then serves the index.html file and assets without any proxies (typical for Rails apps).

The pros and cons of Capistrano based deployment

So what are main advantages of this process? First, it’s very stable and reliable. I have over a year of experience with this process. I’ve seen hundreds of deployments and I know what can go wrong and how to fix it. However, I hate the monolithicity of this process. We cannot easily interfere with the life-cycle of deployment and we cannot do anything special during the deployment without diving into the Ruby code of Capistrano’s tasks. Last, but not least, even if we do, it won’t be usable by the community.

Our new deployment process, based on ember-cli-deploy

Our new deployment process is based on ember-cli-deploy, which I first heard about during EmberCamp. It was clear that we needed to check out this process and try to automate it as much as possible, to see if it would work with our requirements (Netguru is running over 40 projects simultaneously and many of them are using Ember.js on the frontend, with at least two deployable stages - staging and production).

On the other hand, we are currently in the process of moving our deployment flow to Docker. Therefore, my task required not only checking out ember-cli-deploy but also to fit it into our default Docker process. Here’s what I came up with:

I use Capistrano to run a Docker container and fetch our Ember repository. Then, I run ember deploy with all the plugins that we need. Currently these are ember-cli-deploy-build, ember-cli-deploy-redis, ember-cli-deploy-s3, ember-cli-deploy-manifest, ember-cli-deploy-revision-data, ember-cli-deploy-display-revisions, ember-cli-deploy-gzip and ember-cli-deploy-rollbar. With their help, we upload our assets (gzipped) by default to S3 and store index.html in Redis, which is running on the other Docker container. After that, the container that ran ember-cli-deploy is no longer needed and can be switched off.

Asynchronously, API is being run on the other Docker container and is serving the index.html uploaded to Redis on our application domain. Thus, we can easily perform A/B testing of Ember app revisions, and serve a revision based on some query param, or use the last one by default. These two applications can be deployed completely asynchronously and without coupling.

The pros and cons of ember-cli-deploy

First of all, we now have assets on our S3 instances by default, regardless of whether it’s the staging or production environment. We are using a well documented and community supported pipeline which lets us opt into its life cycle with ease and control. We can take advantage of a wide range of add-ons (S3, Redis, gzipping, etc.) and write our own which can be shared back with the community. Actually, speaking of which, you can take a look at ember-cli-deploy-rollbar, which I’ve already developed :)

What are the disadvantages? I have no production and long-term experience with it. Using it will be a learning process, which may lead to some surprises. Additionally, it is a little bit more complex (from my point of view) but due to its advantages, I cannot resist using it :)

Wrapping up

I should note that we have not used this process in a commercial application yet. I have been playing with it on internal applications and right now we are on track to apply it to commercial and production apps. I feel that, thanks to ember-cli-deploy, we will have more control over our deployment process. For example, the addon I developed eventually let us use the full power of Rollbar by uploading the source maps directly to this service without uploading them to the public production environment.

How are you handling automated deployment of Ember apps? Is it similar or completely different? If you have any questions about our process, or would like to know more about config files or anything else - let me know in the comments!