Automated Ember deployments
At Envoy, our deployments are fully automated. In this post, we’d like to show you how we integrated a “lighting fast deployment” strategy using tools like GitHub, Travis, Slack and Dockbit.
We host our assets in S3. Before Ember CLI Deploy, the easiest way to upload assets would have probably been to use a custom grunt task, which getting to work could easily turn into several hours of hitting your head against a wall.
Today, the same process can be achieved by running ember install ember-cli-deploy-s3 and then configuring the deploy file with your AWS credentials.
We are using S3 to serve our index.html instead of Redis. To do so, we are using ember-cli-deploy-s3-index which also allows us to upload different revisions before making it available to our users.
Our config file looks like the following:
With both plugins configured, deploying our dashboard is a matter of running ember deploy staging or ember deploy production. Then we can activate a revision with ember deploy:activate production -r revision.
If we are not sure about which revision to activate, we can look at the list running ember deploy:list staging.
Automate the mundane
After getting Ember CLI Deploy to work, something didn’t feel quite right yet. We were still doing some manual tasks like running the deploy command to ship PRs to staging or even uploading and activating the latest commit in production.
One of Envoy’s core values is automate the mundane, and honoring that value we decided to go deeper and simplify further our deployment process.
Our requirements were:
- Deploy automatically to staging every PR that passes all the tests.
- Deploy every merge into master to staging and production.
- Attach a notification to the PR in GitHub so we can test easily in staging.
- Make master the default index in staging.
- Notify us in slack that a new revision is ready to be activated in production.
Travis
To deploy automatically to staging we created an after_sucess hook in Travis that calls a custom script after the tests have passed. Our script is called travis_deploy.sh and it has the following content:
The previous script always deploys the commit to staging, and if we are on “master” then it also deploys to production. Great! One chore less to run, but we were still missing steps 3 to 5: the PR notifications and slack message.
GitHub
GitHub’s API allow us to create deployment events and attach them to different PRs. We use that to attach a notification when the deployment starts and then include a link to the revision in staging once it has been deploy.
We use the following script called “deploy-to-staging.rb” to generate the notification above:
And then, we edited our deployment script, so the script above is called only if the current branch is not master. Also, we automatically activate staging if the branch is master:
Once we solved requirements 3 and 4 the only thing we had left was to add slack notifications.
Slack
To get a notification in slack we added an incoming webhook and then put the following after activating staging:
Every time master is deployed to production (remember we don’t activate by default), we get a message like the following:
As easy like that, we got our fifth requirement.
Everything was happiness and all that jazz. But, we were still running a manual command to activate the latest revision in master. Using as example the revision above, one of our engineers would have to go to their terminal an run something like ember deploy:activate production -r 926e624, which turned into a boring task.
Dockbit
We started to use Dockbit to automate our API deployments through Slack, and we decided to do the same for our dashboard.
After adding the repository, we created a new pipeline with a single step doing the following:
Dockbit was the missing piece in our workflow, and it help us to automate our deployment process. Now, anyone can activate running a single command in Slack. We edited our “after_success” script to include the activation command, making it easier for us to activate:
Wrapping up
The term “lighting fast deployment” was probably brought to the Ember community after Luke Melia’s talk at RubyConf 2014: Lightning Fast Deployment of Your Rails-backed JavaScript app.
Two years after that, the same process can be replicated quite easily thanks to the tools mentioned above.
Ember CLI Deploy makes a breeze the assets handling part. Travis, GitHub and Slack take care of uploading and notifications, and Dockbit allows everyone on the team to finally ship code to production.
Do you have a different deployment workflow for your Ember apps? We would love to hear about it! At Envoy we love learning from others and we’re always looking for new ways to improve our processes.
