Centric connect.engage.succeed

Continuously deploy your Angular 2 app using Octopus

Geschreven door Renzo Veldkamp - 29 september 2016

Renzo Veldkamp
At the end of the summer, I started on a very interesting Angular 2 project using microservice architecture. Continuous deployment is a must-have, as it makes it very easy to build, test and deploy small sets of functionality in the form of a microservice. I really enjoy working with Angular; recently version 2 became final.

When it comes to deployment, we use Octopus to deploy our Angular 2 app. Read on to find out how we managed to configure our deployment.

The situation

Each one of our microservices is a component that is built and deployed independently of the other microservices. Two microservices take care of communication with the front-end app, one of them providing RESTful services and the other notifications using web sockets (SignalR).

Our front end consists solely of an Angular 2 app and has no server-side back end like ASP.Net MVC.

We develop our code in Visual Studio, store it in TFS source control and test and build it using TFS build server. We don’t have a complete Microsoft ALM suite, so we use Octopus to deploy our microservices and our Angular app.

Our Angular app's TFS build script is very simple — all we need to do is get the required npm packages and copy our sources (together with the packages) to our drop folder. We then finish with 3 Octopus steps that create the Octopus deploy package (NuGet format), push it to the Octopus package repository and create the Octopus release.

Octopus screenshot

The problem

The communication microservices have an endpoint address, which has to be available to the Angular app, so we need some kind of configuration setting. We have opted for a configuration in JSON format and stored it in a JavaScript file called appconfig.js.

var appConfig = {
	"restUrl": "http://localhost:11000",
	"signalrUrl": "http://localhost:11001"

The appconfig.js file is included in the head section of our master page with a straightforward script tag.

<script src="appconfig.js"></script>

So in our Angular app, we have a global JavaScript object called appConfig with appConfig.restUrl and appConfig.signalrUrl properties that we can use in our ‘@Injectables’, like services and factories.

In our @ngModule, we define these values using value providers.

export const Services = [
    { provide: "REST_URL", useValue: appConfig.restUrl },
    { provide: "SIGNALR_URL", useValue: appConfig.signalrUrl },

    declarations: [AppComponent],
    providers: [...Services],
    bootstrap: [AppComponent]
export class AppModule { }

And we use these values in our component by importing the value.

     constructor(private http: Http, private logger: LogService, @Inject("REST_URL") restUrl: string) {
    this.endpoint = restUrl + "/resource/";

All is working well when we run our components on our own machine (we have reached the “it works on my machine” stage).

We then need to enable automated deployment, so the restUrl and the signalrUrl need to be parameterised.

The solution

Octopus has the JSON Configuration Variables Feature, which seems to be an appropriate way of providing our appConfig with the endpoint addresses of each of our environments.

The following notation is used to reference Octopus’ JSON configuration variables:

So we change our appconfig.js to
var appConfig = {
	"restUrl": "#{restUrl}",
	"signalrUrl": "#{signalrUrl}"

We tell Octopus to replace the values with the appropriate endpoints for the target environment in our deployment process.

Octopus screenshot

We also need to tell Octopus that our dev environment runs on server_dev and our test environment runs on server_test.

Octopus screenshot

This means that

And for our test environment the variables with the Test scope refer to server_test.

No human intervention is required and the changes are released very quickly and reliably!


Octopus Deploy's JSON Configuration Variables Feature works like a charm when you want to deploy an Angular 2 app!

Feel free to suggest any better alternatives or improvements to this approach.

About Renzo

Craft Expert Renzo Veldkamp is part of the .NET team within Craft, the development programme for IT professionals (powered by Centric). If you would like to follow his blog, sign up for Craft updates.


Schrijf een reactie
  • Captcha image
  • Verzenden