Better deployment of Angular applications

Recently I got involved with a team having a mix of Angular 1 and Angular 2 applications. Deploying them was tied to a Java back-end, where the results of a manual grunt build step was incorporated in the resulting deployment on Amazon Web Services.

As a general improvement to both the deployment and the testing infrastructure, we wanted to break apart these applications and Dockerize the back-end. For the front-end, we still were in doubt of how to serve this to end users.

Coming from a background where we had our front-end Ember application tested and deployed automatically, manual testing and packaging felt silly. A lot of tooling existed in the deployment infrastructure of ember-cli-deploy and, apart from the naming, being independent from actual Ember code, I went out to compose a reusable deployment package for generic single-page Javascript applications.

The basic idea of deploying single-page Javascript applications: bootstrapping index.html to point to a set of assets.

The basic idea behind deploying single-page Javascript applications is to upload index.html pointing to a unique set of assets, be it JS code, CSS stylesheets or images. A fantastic ecosystem of plugins already exist making deployment to Azure, AWS S3 and other environments a breeze. I created @deployjs/cli and @deployjs/grunt-build to fix the only two pieces of the puzzle remaining:

1. a command line interface (like ember-cli) exclusive for deployment, that is able to discover installed packages and wire up connections to the deployment pipeline;
2. a plugin to build Angular apps.

Deploying Angular applications

On your machine (or in your CI server, which I’ll cover in a follow up post) run npm install -g @deployjs/cli and in your Angular project, install the packages relevant to your deployment scenario. At least run npm install --save @deployjs/grunt-build (or npm install --save @deployjs/angular-build for Angular-CLI based applications).

Fantastic guides of the whole deployment pipeline and plugins are available on the Ember CLI Deploy guides. DeployJS shares most plugins (except for the individual build plugins) with Ember CLI Deploy.

If you were to deploy to S3 (both index.html and the assets), run npm install --save ember-cli-deploy-display-revisions ember-cli-deploy-gzip ember-cli-deploy-gzip ember-cli-deploy-manifest ember-cli-deploy-revision-data ember-cli-deploy-s3 ember-cli-deploy-s3-index. If you were to deploy to Azure Tables and Azure Blob (index.html and assets, respectively) run npm install --save ember-cli-deploy-display-revisions ember-cli-deploy-revision-data ember-cli-deploy-azure-tables ember-cli-deploy-azure-blob. All of these packages kick in in different parts of the pipeline.

A sample execution of the pipeline, displaying different parts being invoked at different steps.

Create config/deploy.js in the root of your application containing your deployment configuration, as described in the Ember CLI Deploy configuration guides. For the case of S3, this looks like:

This assumes AWS_ACCESS_ID and AWS_SECRET_KEY being available as environment variables in your system.

Run deploys deploy --activate to build and deploy your application. That’s all!

Rejoice!

A package for React is also available under @deployjs/react-build. Not using this framework myself at the moment, I am warmly welcoming contributions and feedback.

In a follow up post on front-end CI/CD I have described how from here we set up a continuous integration & continuous deployment setup with Protractor, Bitbucket Pipelines and DeployJS.

Are configuration steps missing for the grunt deployment step? Do you use different building tools than those covered? Did I over-complicate matters or did I take too many shortcuts? Other glaring oversights? Any feedback is welcome.