Ok hands up, up until now this series has been very sparse in terms on Angular specific configuration. That’s about to change!!
To recap, these are the posts so far in this series:
Part 1: Use NPM and gulp build tasks to support Continuous Integration with VSTS and Azure for an AngularJS app
Part 2: Deploy an Angular App to Azure App Services (Web App) with VSTS Continuous Integration Builds
Part 3: Using gulp tasks in Visual Studio Team Services to configure constants for an AngularJS app (this post)
Part 4: Injecting Build Variables into an Angular App with VSTS Continuous Integration Builds
Now things get more interesting on the Angular and ADAL side of things.
I’m hoping you know that the ADAL configuration for an angular app requires us to add things like the Client ID and Tenant ID. These things are very specific to an Azure Tenant, but what happens if we want to deploy our code to a different tenant as was my case. If you’ve read the first post my use case here is that I want my VSTS instance to be able to deploy directly into a customer Azure tenant.
The app by default has the Client ID etc.. for my Azure tenant as this is where testing is carried out and I want to be able to change these before they get deployed into the customer tenant.
Even if you don’t use ADAL in your Angular app you can still use this process, in fact in some of the code I’m going to show you does just that. We don’t use the same API end points through dev/UST/prod right, this very process can update the endpoints for your API’s in different environments.
I have simplified things here, in the real world I use different builds/CI for dev/UAT environments but I’m not going to muddy these waters by adding unnecessary steps. Once you’ve done this once, you are free to set this up how you want.
Ok down to business. The first thing we need to do is add another npm package to our app. We can do this with
This will add the package to our app and save the dependency in our package.json file.
Gulp-ng-config is a gulp package specifically designed to create Angular constants based on a config file.
Next up we need to create a configuration file that we will use to get the values for each environment. Create a file called constants.json and paste the code below.
This file has configurations for two environments, dev and production but you can have as many as you need in here. You will obviously need to change the GUIDS/endpoints to reflect your environment. Also notice that we have some ADAL config settings in here and some app specific ones. You can put anything you wish into these sections.
Now we have the package and the config file we can configure the gulp task in our gulpfile.js file. The snippet below has the gulp tasks for both dev and release.
You can see in the release build task that we’re targeting an angular module called app and that is is going to use the release section from our constants.json file. The task will create us a file called constants.js inside and app folder (as determined by gulp.dest)
You can manually run this task by running the following from a command prompt inside your project directory.
You should now have a file created inside you app folder which will contain a file like the following:
Once you have included this js file from within your HTML file, you can use the constants in your Angular app in the same way as you would normally, for example adalSettings.aadEndpoints to access the ADAL endpoints and appSettings.apiEndPoint to get at the appsetting end point we defined. There are quite a few options within gulp-ng-config so if the output is not quite matching your app, take a look at the docs for it.
Now we have a task that will configure the environment variables for our production site, we can go back and configure VSTS to call our gulp task at build time so we get the correct constants in our Angular application.
Configuring our VSTS build task
Hopefully you have followed the previous posts and already have a build task in VSTS to deploy our source. If not, you might want to head back over there before we move on.
If you remember back we created a gulp task that looked something similar to this
To get the gulp build task to build the production config we simply add the build task before vstsbuild in the Gulp Task(s) field. the field value should become
We could of course chain these in our gulp tasks but this step for me was easier to do it this way.
That should be it, once the code is checked in to the master branch the build process will build our constants file and deploy this along with the rest of our app so it’s configured correctly for our Azure environment.
Hopefully this series of posts has shown you the way to an easier life automating deployment of client side based apps to different azure tenants.