Forem: Frederik Prijck

Reusable HTML in Angular using NgTemplateOutlet

Frederik Prijck — Fri, 14 Feb 2020 22:16:48 +0000

When creating an application, you might find yourself reusing the same HTML. One way to get rid of this could be to make use of components. Even tho I love using components for this, Angular allows us to reuse HTML without introducing components as well.

Recently I find myself using this as I wanted to limit the amount of refactoring in the current PR (so I didn't want to move parts of the HTML and code into a component) while I still wanted to introduce reusability in the HTML.

Take a look at the following example:

    <h1>Movies</h1>
    <div *ngFor="let movie of movies">
      <span>{{ movie.name }}</span>
        <p>{{ movie.description }}</p>
        <button (click)="onClick(movie)">Click Me</button>
    </div>

    <h1>Favorite Movies</h1>
    <div *ngFor="let movie of favoriteMovies">
      <span>{{ movie.name }}</span>
        <p>{{ movie.description }}</p>
        <button (click)="onClick(movie)">Click Me</button>
    </div>

As mentioned, to limit duplication and introduce reusability we could move the content of our ngFor into its own component, add the appropriate input and outputs and set up the bindings appropriately.

Apart from using a Component, we can also make use of Angular's NgTemplateOutlet. I'll generally recommend using a component. However, if you find your self in a situation where the HTML you wanna reuse is so big and bound to the current component in so many ways, using NgTemplateOutlet might be a first step into making the HTML reusable. Another reason to use NgTemplateOutlet could also be when the HTML is so simple, that introducing a separate component might not be making things easier to grasp.

    <ng-template #itemTemplate>
      <span>{{ item.name }}</span>
        <p>{{ item.description }}</p>
        <button (click)="onClick(item)">Click Me</button>
    </ng-template>

Moving the content of our ngFor into an ng-template is pretty straightforward. However, as we want to render this template several times, each time for a different item, we'll need to declare some kind of context for the ng-template so that angular knows how to bind the data. In our case, we'll be adding let-item to the ng-template.

    <ng-template #itemTemplate let-item>
      <span>{{ item.name }}</span>
        <p>{{ item.description }}</p>
        <button (click)="onClick(item)">Click Me</button>
    </ng-template>

Using this template can be done by using the ngTemplateOutlet directive on an ng-container component.

    <ng-container [ngTemplateOutlet]="itemTemplate">
    </ng-container>

We can add a context object to ngTemplateOutlet which allows us to provide it with a value to use as the item we have defined on our ng-template.

A context object should be an object, the object's keys will be available for binding by the local template let declarations. Using the key $implicit in the context object will set its value as default.

What this means is that we can either use let-item="movie" and provide the context as an object containing a movie property: [ngTemplateOutletContext]="{ movie: movie }" or use let-item and [ngTemplateOutletContext]="{ $implicit: movie }". Both of them will make the movie available as item inside the template.

    <ng-container [ngTemplateOutlet]="itemTemplate" [ngTemplateOutletContext]="{ $implicit: movie }">
    </ng-container>

Putting everything together, we now should be able to refactor our HTML to look like this:

    <h1>Movies</h1>
    <div *ngFor="let movie of movies">
      <ng-container [ngTemplateOutlet]="itemTemplate" [ngTemplateOutletContext]="{ $implicit: movie }">
        </ng-container>
    </div>

    <h1>Favorite Movies</h1>
    <div *ngFor="let movie of favoriteMovies">
      <ng-container [ngTemplateOutlet]="itemTemplate" [ngTemplateOutletContext]="{ $implicit: movie }">
        </ng-container>
    </div>

    <ng-template let-item>
      <span>{{ item.name }}</span>
        <p>{{ item.description }}</p>
        <button (click)="onClick(item)">Click Me</button>
    </ng-template>

We can even add another ng-template to reuse the list. For demonstration purposes, we'll not use the $implicit property on the NgTemplateOutlet's context in this case. Instead, we'll explicitly assign our value to a property, other than $implicit, and use that same property in let-list="list", where the right side of the assignment refers to the context property while the left side is defining a variable usable in the ng-template.

    <h1>Movies</h1>
    <ng-container [ngTemplateOutlet]="listTemplate" [ngTemplateOutletContext]="{ list: movies }">
    </ng-container>

    <h1>Favorite Movies</h1>
    <ng-container [ngTemplateOutlet]="listTemplate" [ngTemplateOutletContext]="{ list: favoriteMovies }">
    </ng-container>

    <ng-template #listTemplate let-list="list">
      <div *ngFor="let item of list">
          <ng-container [ngTemplateOutlet]="itemTemplate" [ngTemplateOutletContext]="{ $implicit: item }">
            </ng-container>
        </div>
    </ng-template>

    <ng-template #itemTemplate let-item>
      <span>{{ item.name }}</span>
        <p>{{ item.description }}</p>
        <button (click)="onClick(item)">Click Me</button>
    </ng-template>

Note: The ngTemplateOutlet directive can also be used as a structural directive:

<ng-container *ngTemplateOutlet="itemTemplate; context: { $implicit: item }">
</ng-container>

Conclusion

Even tho using Components is still the most ideal way in Angular to introduce reusable blocks, Angular's ngTemplateOutlet allows for a way to make use of reusable blocks of HTML without introducing new components.

You can find a running example at: https://stackblitz.com/edit/angular-fkqhbz

Converting a Promise into an Observable

Frederik Prijck — Mon, 04 Nov 2019 21:34:32 +0000

When working with rxjs, you might find yourself in a situation where you want to integrate a promise in a reactive code base. In order to embrace the full reactivity, it's a good idea to convert that promise into an observable so we can easily pipe other operators or even combine it with other streams.

Previously, rxjs had an operator that was specifically designed for this use-case: fromPromise. Current versions of rxjs have dropped fromPromise in favor of from, however, there's no real difference in usage. The from operator, apart from arrays and strings, accepts a promise in order to convert it into an Observable.

If you are interested in knowing how it handles a promise or how it defines whether or not it's a promise that's being passed in, have a look at https://github.com/ReactiveX/rxjs/blob/master/src/internal/observable/from.ts#L114 and https://github.com/ReactiveX/rxjs/blob/master/src/internal/util/subscribeTo.ts#L20

    const url = 'https://jsonplaceholder.typicode.com/todos/1';

    function getTodo() {
      return fetch(url)
        .then(response => response.json());
    }

    getTodo().then(console.log);

The above code is the promise representation of the snippet that we want to convert to using observables in such a way that we can integrate it with other, existing, observables.

This article is about a function that's returning a Promise that we'll be converting into an Observable, not just a standalone Promise.

Implementing the from operator comes down to wrapping the promise with the from operator and replacing .then(...) with RXjs' map(...):


    const url = 'https://jsonplaceholder.typicode.com/todos/1';

    function getTodo() {
      return from(fetch(url))
        .pipe(map(response => response.json()));
    }

    getTodo().subscribe(console.log);

That should do it, right? We have successfully converted the promise returning function into a function that's returning an Observable. We can now start combining this with other Observables/Operators so that we can create more advanced streams.

But what if I told you this probably isn't what you want (yet)?

Lazy Observables

When using observables, it's not expected that anything happens for as long as there is no active subscription. However, removing the subscription from the above code will still trigger the HTTP call. You can see this in action here: https://stackblitz.com/edit/rxjs-bb626s

If you would inspect the DevTools' network tab, you will notice that the HTTP call is indeed triggered, even tho we do not have any subscription.

We can solve this by either using an existing rxjs operator, in combination with the from operator we're already using or you can decide to build the observable from scratch.

Using the defer operator

Rxjs' defer operator can be used to wait until an observer subscribes before creating the actual observable.

    function getTodo() {
      return defer(() => from(fetch(url)));
    }

    const getTodo$ = getTodo();

    setTimeout(() => {
      getTodo$.subscribe();
    }, 5000);

This will ensure that the HTTP call is only triggered after 5000ms, which is the moment that we're adding a subscription to the observable.
You can see this in action https://stackblitz.com/edit/rxjs-fgwokv

Note: Most of the time, you might be bringing in asynchronous data as a matter of a mergeMap/switchMap/exhaustMap/concatMap operation, which might be returning an Observable that's originating from a Promise in some cases. If that's the case, we, technically, have no need to use defer as the Observable will not be created until the source Observable emits. However, it's still not a bad idea to use defer either way to ensure the Promise is lazy, no matter how it's used.

Building the observable from scratch

Even tho I'd recommend using existing rxjs operators when possible, I think for converting a Promise to an Observable it's worth taking control over the Observable creation ourselves so that we have more control over what happens when we unsubscribe from the Observable (which we will cover in promise cancellation).

    function getTodo() {
      return new Observable(observer => {
        return from(fetch(url)).subscribe(observer);
      });
    }

    const getTodo$ = getTodo();

    setTimeout(() => {
      getTodo$.subscribe();
    }, 5000);

The above code will create an observable based on the promise and only subscribe to it after 5000 ms. If you would have a look at this stackblitz https://stackblitz.com/edit/rxjs-4zj1bx, you will see that the HTTP call is only triggered after 5 seconds. So our observable is now lazy in such a way that it will only resolve the promise (and trigger the HTTP call) when a subscription is added.

Note that we are adding an explicit subscription which we're returning from the Observable's constructor callback as the teardown logic. Doing so ensures that that subscription is cleanup whenever we unsubscribe from the observable returned by getTodo().

Promise cancellation

We're still missing one crucial part in our Promise to Observable conversion. In our case, the promise was representing an HTTP call. Whenever we unsubscribe from the observable before the HTTP call is finished, we probably want to abort the open HTTP request.

    function getTodo() {
      return new Observable(observer => {
        const abortController = new AbortController();
        const subscription = from(fetch(url, {
          signal: abortController.signal
        })).subscribe(observer);

        return () => {
          abortController.abort();
          subscription.unsubscribe();
        }
      });
    }

    const getTodo$ = getTodo();

    setTimeout(() => {
      const sub = getTodo$.subscribe();
      sub.unsubscribe();
    }, 5000);

AbortController is a built-in interface that allows us to cancel DOM requests, including Promises. Even though a lot of async operations might require a custom AbortController implementation, the fetch API supports the AbortController by default. This means that all we need to do is create an AbortController instance, pass it's signal property to the fetch method and call abort whenever appropriate, in our case meaning in the TearDownLogic, which is called whenever we unsubscribe from the Observable. You can read more about Aborting a fetch on https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API.

Here's a stackblitz containing the functionality to abort the HTTP call: https://stackblitz.com/edit/rxjs-7wc1rb. If you'd inspect the DevTools' network tab, you'll notice an HTPP call is being triggered but it's instantly canceled.

Rxjs fetch operator

Rxjs has built-in support for converting the fetch API to an observable (see: https://github.com/ReactiveX/rxjs/blob/0e4849a36338133ac3c1b890cd68817547177f44/src/internal/observable/dom/fetch.ts
). As you might notice, it is also using the AbortController to cancel the HTTP call when unsubscribed from the Observable (even tho it's slightly more complicated because this article sticks to the basics of promise cancelation). You probably want to be using that instead of hard-crafting your own. However, this article is intended to give you an example on how we can convert any promise to an Observable.

Continuously Deploying Angular to Azure Storage with Azure DevOps

Frederik Prijck — Wed, 30 Oct 2019 21:57:55 +0000

Introduction

In a previous article, we saw how to use Azure DevOps to deploy an Angular application to an Azure App Service running .NET Core.

Even though an Angular application works perfectly on an Azure App Service, we don't need a .NET runtime (or any other runtime such as nodejs, Ruby, PHP, ...) to host our Angular application if it's not using Server Side Rendering.

If you're using Server Side Rendering, you do need a runtime such as nodejs to be able to run a process that's responsible for rendering, and serving, the Angular application. In this article, we're deploying an application that doesn't use Server Side Rendering, so we have no need for such a runtime.

An Azure Storage Account is mostly used for storing blobs, and files, but it also contains a queue, and a NoSQL database with which you can integrate.

Apart from the above features, Azure Storage Account provides a way to host a static (HTML, CSS, JavaScript, and other assets) site, such as an Angular application. The hosting is free. You're only being billed for the blob storage taken by the files of your application. You can find more details on Azure Storage Blob pricing at https://azure.microsoft.com/en-us/pricing/details/storage/blobs/.

Creating a Storage Account

We can create a Storage Account through the Azure Portal; ensure you have an active subscription to which we can add the Storage Account. You can create one (here if you don't have one yet. Make sure you choose a Free Trial subscription in order to not be charged. A Free Trial shouldn't be used for production).

Inside the Azure Portal, navigate to All Services, and search for Storage accounts. Selecting Storage accounts from the search results will bring you to the Storage accounts overview. Click "add" to create a new Storage Account, and fill in the required information in the Basics tab:

Select the subscription and resource group in which we want to create the storage account, and provide it with a name (the name has to be unique across all storage accounts in Azure). The other options can be left untouched. You can find more information about these configuration settings at https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction#types-of-storage-accounts.

We don't need to change anything in the other tabs (Networking, Advanced and Tags). Go ahead and create the Storage Account. Azure should navigate you to the deployment details, showing the progress of the deployment. Once you have deployed, you should be able to click "Go to resource" in order to go to the created Storage Account.

As mentioned before, there are different ways we can make use of an Azure Storage. We're not going to cover the details of any of its features, other than hosting a static website.

Configuring a Static Website

You can access the configuration regarding static websites from the Storage Account's side-menu (Settings ⇒ Static website)

As static website hosting is disabled by default, we need to enable it in order to be able to host a static website inside a Storage Account. Once enabled, we need to provide an index document name and, optionally, an error document path.

The error document path should point to an HTML file that will be rendered when a request to Azure Storage returns a 404. Currently, we don't have such a file, so let's keep it empty for this article.

Once saved, you should see a primary and secondary endpoint being listed. These are the URLs on which the application, once deployed, will be available. Apart from the URL, you'll also see that a container, named $web, has been created to host the static website.

As we haven't deployed any files yet, trying to open any of the endpoint URL's in your favorite browser will show the default 404 message (this is the message that would be replaced with an HTML file if we had configured an Error document path).

Configure a Release Pipeline for a Storage Account

We'll be creating a release pipeline that will use the artifacts published as part of the build pipeline that was configured in https://dev.to/thisdotmedia/continuously-integrating-angular-with-azure-devops-2k9l. This article assumes that the Angular application that was used in the above article has been updated to include environmental configuration as described in https://dev.to/thisdotmedia/runtime-environment-configuration-with-angular-4f5j.

When inside an Azure DevOps project, create a new Release Pipeline by selecting Pipeline ⇒ Releases ⇒ New ⇒ New Release Pipeline

We're not going to use a template for our release pipeline, so you can choose to start with an empty job instead of selecting a preconfigured template.

As Azure DevOps supports multiple stages, you can provide a name for the stage that's created by default, or you can keep Stage 1 as its name.

Adding build artifacts

Let's start by adding the artifacts that we want to deploy to Azure Storage. Click Add an Artifact, select the Build source type (as the artifacts are stored within the build pipeline), and select the appropriate build pipeline from the source dropdown. You can keep the default values for both the version to deploy, as we always want to deploy the latest version, and the source alias. The source alias is the folder that will be used to download the artifacts. We will be using this value throughout the next steps when manipulating, and uploading the artifacts.

Adding deployment tasks

As we have started with an empty job, there are no tasks defined yet. We'll need to add a task to deploy the artifact's files to an Azure Storage Account. To do so, we can make use of the integrated Azure file copy task by going to the tasks section, clicking the '+' on the Agent job, searching for Azure file copy, and clicking add.

When adding an Azure file copy task, you will need to provide the required information in order for Azure DevOps to know what files have to be deployed to which destination. This includes both the Azure Subscription, and the Storage Account information.

As we're going to deploy the build artifacts, which are configured to be available inside the release definition, we'll need to provide the path to the source that we want to deploy. You can navigate the artifacts, and select the appropriate folder, by clicking the ... button.

Once we have configured the files that should be deployed, select your Azure Subscription, select Azure Blob as the Destination Type, choose the appropriate Storage Account that you want to use, and provide $web for the container name (this is the default container name used by Azure DevOps when enabling static websites inside an Azure Storage Account).

Environment specific configuration

As mentioned in the previous article (https://dev.to/thisdotmedia/runtime-environment-configuration-with-angular-4f5j), we're not making use of the built-in Angular environment system in order for our application to make use of environment-specific configuration.

As we want to avoid rebuilding the application in order for it to use environment-specific configuration, we're using a JSON file that's served as part of the assets directory, and is retrieved in our Angular application using an Http Request. You can find a detailed overview on how to configure this in the article mentioned above.

We will need a File transform task to modify the contents of the config.json file as part of our release pipeline's stage (in case of multiple stages, every stage can have its own step, and can replace the contents with different values before deploying). Add the task, and configure it to target the assets/config.json file inside our web-app artifact.

Ensure this task is executed before deploying the files to Azure Storage.

In order for Azure DevOps to know what names and values it has to use while transforming the config file, we will need to create release pipeline variables. The file transform task will use all the variables, and update values based on its name.

All we need for now is for an apiUrl to be configurable for each environment, so we'll need an apiUrl pipeline variable (I went with localhost locally and https://www.thisdot.co for the environment):

Continuous Deployment Trigger

Even though we could save the configuration, and create manual releases at this point, in order to continuously deploy our artifacts, we'll need to set up a trigger. Click on the lightning strike symbol that's showing up on your artifact in the pipeline section, enable the Continuous deployment trigger, and add a branch filter for the branch you want to deploy (which is master in this case). We don't need to enable the Pull request trigger for this article.

You can save the release pipeline, and create a new release, either by running a new build, and making use of the continuous deployment trigger, or by manually creating a new release.

Once the deployment is finished, navigating to one of the Azure Storage endpoint URL's should show the Angular application, including the correct environment configuration being logged to the console.

Conclusion

Using an Azure Storage Account to host a static web application doesn't make deploying any different from deploying to an Azure App Service. However, when we're not making use of any server-side rendering technology, using a runtime such as .NET/PHP/Java is unnecessary, so we have no need to use an App Service.

Making use of Azure Storage lowers the costs since hosting itself is free, and you're only billed for the blob storage taken by the application's files. Even though App Services has free variants, once you start adding things such as custom domains, you'll need to use one of the paid variants. The cost of these are generally higher than that of an Azure Storage Account if all you're hosting is a static website.

Runtime environment configuration with Angular

Frederik Prijck — Wed, 30 Oct 2019 15:28:27 +0000

When planning to deploy an Angular application, you might have the need for some configuration that can be different for every environment that's hosting the application. Even when you are only deploying to a single environment, the configuration can be different from the one used for local development. Often, a frontend application needs to communicate with a backend, whose URL can be different for each environment. In this article, we'll modify an Angular application to make use of a configurable API URL in such a way that it can differ for each environment to which you're deploying.

Angular environments

Angular has a built-in environment system that allows you to specify configuration for multiple environments. When building the application with a given target environment, Angular CLI will replace the environment.ts file with the content of the environment-specific environment file (e.g. environment.qa.ts, environment.prod.ts).

Even though this works quite well, the downside of this is that we need to recompile and reupload the artifacts for each environment to which we are planning to deploy. As the idea behind an Azure DevOps release pipeline is to use a single build artifact, and deploy them to, theoretically, an endless amount of environments, this approach doesn't work well with the way we're setting up Continuous Deployment.

Runtime environment configuration

As we need to be able to deploy our application to multiple environments using a different configuration without recompiling the application for a specific environment, we will need to have some kind of runtime configuration. This means we'll need to swap out the environment configuration after the artifacts are built.

One way we can do this in an Angular application is by including a config.json file in the assets directory that contains the configuration settings. Including the JSON file in the assets directory ensures it's being copied to the dist folder when running ng build without the need to make any changes to the angular.json file.

Go ahead and create the config.json file using a single apiUrl property:

    {
        "apiUrl": "http://localhost"
    }

We can load the config file as part of an APP_INITIALIZER, ensuring the application isn't started before the config file is loaded. Before we can include an actual APP_INITIALIZER, we will create a service that's responsible for fetching the config.json file using Angular's HttpClient.

    @Injectable({
      providedIn: 'root'
    })
    export class ConfigService {
      config: Config;

      constructor(private http: HttpClient) {}

      loadConfig() {
        return this.http
          .get<Config>('./assets/config.json')
          .toPromise()
          .then(config => {
            this.config = config;
          });
      }
    }

Once we added the above service to an Angular application, we can hook it into Angular's APP_INITIALIZER:

    export const configFactory = (configService: ConfigService) => {
      return () => configService.loadConfig();
    };

    @NgModule({
      ...
      providers: [
        {
          provide: APP_INITIALIZER,
          useFactory: configFactory,
          deps: [ConfigService],
          multi: true
        }
       ],
       ...
    })
    export class AppModule { }

Wherever we need access to the environment-specific configuration, we can inject the ConfigService, and access the config property.

    @Component({
      selector: 'app-root',
      templateUrl: './app.component.html',
      styleUrls: ['./app.component.css']
    })
    export class AppComponent {
      title = 'ng-azure-devops';

      constructor(configService: ConfigService) {
        console.log('config', configService.config);
      }
    }

In the above component, we're injecting the ConfigService in order to log the entire config object to the console. This should allow us to inspect whether or not the configuration has been set correctly for any environment. In a real application, you probably need to inject the config in the services that are responsible for calling that environment-specific API, and use the API URL to build the endpoint URL.

Replacing the configuration file

Now that we have everything in place to include configuration at runtime using a JSON file, all that's left to do is to replace that file with the environment-specific configuration, and it will be picked up when running the application.

One way could be to include multiple environment configuration files in source control, (config.qa.json, config.prod.json, ...) and swap them during deployment.

However, I prefer not to add a separate config file for each environment to which we're deploying. Instead, I think it's a good idea to use a single file, and update its content as part of an automated release pipeline. This allows for a separation between the code-base, and the different number of environments to which it's being deployed.

This Dot Inc. is a consulting company which contains two branches : the media stream and labs stream. This Dot Media is the portion responsible for keeping developers up to date with advancements in the web platform. In order to inform authors of new releases or changes made to frameworks/libraries, events are hosted, and videos, articles, & podcasts are published. Meanwhile, This Dot Labs provides teams with web platform expertise using methods such as mentoring and training.

Continuously Deploying Angular to Azure App Service with Azure DevOps

Frederik Prijck — Tue, 10 Sep 2019 19:08:22 +0000

Introduction

In the previous article, we saw how to integrate an Angular application with Azure DevOps so that we are continuously building our project, and publishing the output(s) as artifacts, attached to the build pipeline.

In this article, we'll be creating a Release Pipeline to automatically deploy to an Azure App Service whenever such an artifact was published.

Creating the Release Pipeline

We'll be creating the release pipeline in the same project as the build pipeline for which we want to deploy the artifacts.

Navigate to releases from the project's sidebar, and select New pipeline.

As we are going to make use of an Azure App Service to host our Angular application, select the Azure App Service deployment template, and click apply:

Azure DevOps supports multiple stages in a single Release pipeline (e.g. Development, Testing, Production environments). For this article, we'll only be using one stage, which is already created by default, using the name Stage 1. If you want you can give it an appropriate name, or keep it as is.

When selecting the Azure App Service deployment template, a task is automatically added to the Release pipeline. Head over to Tasks section, and fill in the required information. We'll need to select the Azure subscription. (Here is how you can create one if you don't have it yet. Make sure you chose Free Trial subscription to not be charged. Free Trial shouldn't be used for production) on which the App Service is running.

If this is the first time you're connecting Azure DevOps to your Azure account, you will need to click Authorize. Once we've authorized Azure DevOps to communicate with our Azure Subscription, we can select the App Service that will host our application (make sure you've selected value from the dropdown, and not just typed it manually):

If you don't have the App Service created on the Azure Portal, you need to open Azure Portal Dashboard, and find App Service button on the left. Then, select it, and click the Add button. Here what you should see:

Adding build artifacts

Now that we've configured the destination environment for our deployment task, go to the Pipeline section (to the left of the Tasks section) to add the artifact we want to deploy. Click Add Artifact, select the Build source type (as the artifacts are stored within the build pipeline), and select the appropriate build pipeline from the source dropdown. You can keep the default values for both the version to deploy, as we always want to deploy the latest version, and the source alias. The source alias is the folder that will be used to download the artifacts. We will be using this value throughout the next steps when manipulating, and uploading the artifacts.

This will make all artifacts that belong to the build pipeline available in the release pipeline. They will be downloaded automatically when the release pipeline is triggered.

Now that we have both the artifacts, and the environment configured, we'll need to make one extra change to our deployment. For the Deploy Azure App Service task, we will need to specify which artifact it has to deploy.

Our Build pipeline publishes two artifacts:

Code Coverage report
The ng build build output which we want to deploy

If needed, we could add an extra step to deploy the code coverage artifact, but for this article, we're only going to deploy the ng build output, which is being published as an artifact with the name web-app, and made available in our Azure App Service deployment step inside the _ng-azure-devops directory (which is the source alias that was configured when adding the artifacts).

Now go to Tasks tab in our pipeline, click on deployment task, and change the Package or Folder to $(System.DefaultWorkingDirectory)/_ng-azure-devops/web-app.

Continuous deployment trigger

Save the changes for your release pipeline, and trigger a new build (by either making a code change or by manually queuing it from the build pipelines.

Once the build and release pipelines are completed successfully, you should be able to navigate to the App Service's URL, and see the default Angular project.

Environment specific configuration

When deploying our application, we might need some configuration that can be different for every environment that's hosting our application. As often frontend applications need to communicate with a backend, we'll be making the API URL configurable so that it can differ for each environment.

Angular environments

Angular has a built-in environment system that allows you to specify multiple environment configurations. When building the application with a given target environment, Angular CLI will replace the environment.ts file with the content of the environment-specific environment file (e.g. environment.prod.ts)

Even though this works quite well, the downside of this is that we need to recompile and reupload the artifacts for each environment to which we are planning on deploying. However, the idea behind an Azure DevOps release pipeline is to only build the artifacts once, while still being able to deploy them to, theoretically, an endless amount of environments.

Runtime environment configuration

As we need to be able to deploy our application to multiple environments using a different configuration, we will need a way to swap out environment configuration after the artifacts were built.

A typical way to do this in an Angular application is by including a config.json file in the assets directory that contains the configuration. Putting it in the assets directory ensures it's being copied to the dist folder when running ng build.

{
    "apiUrl": "http://localhost"
}

We can load the config file as part of an APP_INITIALIZER, ensuring the application isn't started before the config file is loaded.

@Injectable({
  providedIn: 'root'
})
export class ConfigService {
  config: Config;

  constructor(private http: HttpClient) {}

  loadConfig() {
    return this.http
      .get<Config>('./assets/config.json')
      .toPromise()
      .then(config => {
        this.config = config;
      });
  }
}


export const configFactory = (configService: ConfigService) => {
  return () => configService.loadConfig();
};

@NgModule({
  ...
  providers: [
    {
      provide: APP_INITIALIZER,
      useFactory: configFactory,
      deps: [ConfigService],
      multi: true
    }
   ],
   ...
})
export class AppModule { }

Wherever we need access to the environment-specific configuration, we can inject the ConfigService to use the config property.

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  title = 'ng-azure-devops';

  constructor(configService: ConfigService) {
    console.log('config', configService.config);
  }
}

In the above component, we're injecting the ConfigService in order to log the entire config object to the console. This should allow us to inspect whether or not the configuration has been set correctly for our environment. In a real application, you probably need to inject the config in your services that are responsible for calling that environment-specific API.

We don't need to add a separate config file for each environment to which we're deploying. Instead, we'll use a single file, and update its content as part of the release pipeline. This allows for a separation between your code-base, and the different amount of environments it's being deployed to.

Adjust tests, and make sure they pass. Then commit, and push the changes to the repository.

Modifying config.json on Azure DevOps

We'll need to modify the contents of config.json as part of a task in the release pipeline, move over to the release pipeline, edit it, and add a File transform task before deploying our application.

There are three important parts of this task that we need to configure:

Package or folder: points to the correct artifact for which we want to transform a file
File format: Azure DevOps' File Transform task supports both XML and JSON. We'll be using JSON for this article.
Target files: Include the path to the config.json file, relative to the root of your artifact.

That's all we need to do in order for the File Transform task to start processing the config.json file prior to deploying it.

In order to define what names and values it should use while transforming the config file, we will need to create variables as part of the release pipeline. The file transform task will try and find all variable's names, and update its value accordingly.

For this article, all we need is an apiUrl variable with a value different from what we have locally (I went with localhost locally and thisdot.co for the environment):

If you have a more complex configuration object, using nested paths, you need to specify them using a JSONPath expression, see https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/file-transform?view=azure-devops for more information on the file transform task.

Enabling JSON files on Azure

An Azure App Service doesn't allow JSON files to be served by default. In order to do so, we need to add a web.config file (more info on configuring system.webServer can be found at https://docs.microsoft.com/en-us/iis/configuration/system.webserver/).

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.webServer>
        <staticContent>
            <remove fileExtension=".json" />
            <mimeMap fileExtension=".json" mimeType="application/json" />
        </staticContent>
    </system.webServer>
</configuration>

We could add this config file to our git repository, and ensure it's also copied to the dist folder when running ng build. This get's a little complex if all we need is to enable JSON.

Luckily, we can also add a file as part of a release pipeline. As our web.config file will be very small, I'll be using this approach. This, again, keeps our source-code independent on where we'll be hosting it.

Move over to the release pipeline, and add a new task, either before or after transforming the config file. We do need to ensure this task is added before deploying the artifacts, so ensure it's executed before the deployment task.

The task for creating a file is not part of Azure DevOps itself. You can get it for free through the Marketplace: https://marketplace.visualstudio.com/items?itemName=eliostruyf.build-task

Once installed, edit the release pipeline, and add a new File Creator task, providing:

file path: this is the path, including filename, for the file that's being created
file content: Any content that should go in the created file.

Save the release pipeline, and create a new release (either by triggering a new build, or manually creating a release using the last known artifacts).

Once the release was completed successfully, navigating to the URL of the App Service should show the default Angular application as well as a console output showing the environment-specific configuration.

Conclusion

Azure DevOps makes setting up continuous deployment a breeze. In only a few steps, we have integrated an Angular application to automatically deploy our artifacts to one or more environments, providing each environment with the required environment-specific configuration.

This should take away a lot of time from manual deployments, allowing your team to focus on the quality of the software instead.

This article was written by Frederik Prijck who is a Software Engineer at This Dot.

You can follow him on Twitter at @frederikprijck.

Need JavaScript consulting, mentoring, or training help? Check out our list of services at This Dot Labs.

Continuously Integrating Angular with Azure DevOps

Frederik Prijck — Thu, 05 Sep 2019 23:23:48 +0000

Introduction

Azure DevOps is a Microsoft product that, alongside other features such as Source Code Management and Project Management, allows your team to set up Continuous Integration for their project(s).

Continuous Integration is a development practice that enables your team to improve quality, and deliver more stable software, benefiting both the team, and the end-user.

With continuous integration, several checks (referred to as a pipeline) are automatically run on certain triggers, such as a code change. These checks typically ensure that the code can be compiled successfully, and that all tests are passing. Automatically running these checks, in an isolated environment, takes away most of the issues that do work on my machine, and ensures our code-base is in good health at all times.

Angular application

For this demo, we'll be using a default Angular CLI application for which we'll be adding a Build pipeline on Azure DevOps.

Ensure you have the latest version of @angular/cli by running npm install --global @angular/cli, and create a new angular application using ng new ng-azure-devops --skipInstall=true; we don't need Angular routing, and you can pick the stylesheet format of your choice.

Creating the Azure DevOps project

If you don't have a project on Azure DevOps yet, head over to https://dev.azure.com, and create a new one for this demo, provide a name, and (optionally) a description. You can choose which visibility you want. I'm going with public, but private would work just fine.

Once the project is created, you'll be taken to the project's dashboard.

Adding the code to Azure DevOps

On your project's sidebar, you should find Repos. Clicking it will take you to the default Git repository that was created for this project. You can add more repositories in your project if needed, so you don't need to create multiple projects if your application is spread over multiple Git repositories. For this article, we only need a single repository, so we're going to use the one that was created by default.

The repository's home should tell you it's empty, and provide you with instructions to push your code to the repository.

You'll need to configure your SSH key or use the Git credential manager in order to be able to commit to a repository on Azure DevOps.

Once authentication is configured, commit, and push the Angular project that we've created using the Angular CLI.

If you want to use GitHub, you can add your code to Github, and connect your Github account in Azure DevOps by going to the Project Settings > Github Connections (it's categorized under Boards in the Project Settings). You'll need to select the GitHub organization, as well as the repositories you want to integrate into the current project.

The next steps will work identical for both GitHub repositories and Azure DevOps repositories.

Creating a build pipeline

Now that we have our code either in an Azure DevOps repository or on GitHub (with our GitHub account connected through Project Settings), we can create a build pipeline for that repository by navigating to Pipelines from the project's sidebar.

Click on New Pipeline, select Azure Repos Git or GitHub (or anything else if you're using any of the other available options), click the corresponding repository (if you selected GitHub, you'll be prompted to authorize Azure Pipelines) and select Node.js with Angular as the pipeline configuration. This will preconfigure the pipeline to run npm install, and ng build —-prod.

In the review step, we'll see an example of the yaml file that's being generated by Azure DevOps.

# Node.js with Angular
# Build a Node.js project that uses Angular.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '10.x'
  displayName: 'Install Node.js'

- script: |
    npm install -g @angular/cli
    npm install
    ng build --prod
  displayName: 'npm install and build'

The default configuration will trigger for each change on the master branch. It'll use an ubuntu image, and executes two steps:

Install Node.js
Install dependencies and build the application.

Clicking Save And Run will add the yaml file your repository, keeping your build pipeline configuration together with the source code. We can even make changes to the yaml file locally, and commit them, Azure DevOps will pick up these changes, and update your build pipeline accordingly.

Creating a separate branch, and starting a pull request allows you to not merge this configuration in master before it's completely configured in the way that you want. To simplify things, we'll be committing changes directly to master.

If you prefer to use a separate branch, you can still do so. However, do know that builds are not triggered automatically as long as there's no azure-pipelines.yml file on master branch. This means you'll need to manually trigger builds until your configuration is merged into master.
In case of creating a pipeline, clicking Save and Run will run it either way, but as we'll be making changes to the source code, builds will not be triggered automatically.

Once the configuration file has been saved, a new build is triggered, and after a while, all steps should have been completed successfully.

Some of the above steps are added by Azure DevOps (Prepare, Initialize, Checkout, Post Checkout and Finalize), while others are defined as part of our yaml configuration (Install Node.js and npm install and build). If you want to get more information for a specific step, clicking it will show all the output for that particular step:

Finetuning the build pipeline

We haven't made any changes to the default Node.js with Angular configuration yet. Before adding additional steps, let's change the configuration in such a way that installing the dependencies, and building the project are two separate steps: remove the global installation of @angular/cli and make use of npx instead.
To edit the build pipeline, click pipelines from the project's sidebar, select the corresponding build pipeline, and click edit on the upper right corner:

When clicking edit, Azure DevOps will open an editor for the yaml file that was created earlier. Edit the contents of the file so that it's identical to the yaml configuration below:

# Node.js with Angular
# Build a Node.js project that uses Angular.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '10.x'
  displayName: 'Setup Environment'

- script: npm install
  displayName: 'Install Dependencies'

- script: npx ng build --prod
  displayName: 'Build'

Saving the configuration should trigger a new build. You should see the Install Dependencies, and Build steps being two individual steps.

Azure DevOps is now integrated to run ng build on every commit to master. Apart from building the project, we might also want to run all of the unit tests so that we know that all of the code is still working as expected.

Running Unit Tests on Azure DevOps

Before we'll be able to run the unit tests on Azure DevOps, we'll need to make some changes to the project that was generated using Angular CLI.

As the host, on which the pipeline is executing all of the automated steps, has no Chrome installed, we'll need to add puppeteer to be able to use ChromeHeadless on Azure DevOps.

npm install puppeteer --save-dev

Open karma.conf.js, and add the following to the top:

const process = require('process');
process.env.CHROME_BIN = require('puppeteer').executablePath();

This will load puppeteer, and use its executablePath for the CHROME_BIN environment variable, allowing for karma to use puppeteer when running Chrome or ChromeHeadless.

As a last step, update the karma.conf.js file to use the ChromeHeadless browser.

{
  //...
  browsers: ['ChromeHeadless']

  //...
}

Updating karma.conf.js to use puppeteer will use puppeteer on your local machine as well. If this is not something you want, you can create a copy of the karma.conf.js file, name it karma.conf.ci.js (or anything you like), and pass it to the ng test --karmaConfig karma.conf.ci.js command when running it in the pipeline (we'll be configuring this later).

Commit and push these changes to the repository. This will trigger a build, but this won't execute the tests yet as we first have to update the build pipeline to run the tests. Add a new step to the configuration in Azure DevOps, either before or after the Build step.

- script: npx ng test --watch=false
  displayName: 'Tests'

Once saved, the build should be triggered and completed successfully, including a Tests step. Clicking on the Tests step should show you the same information you would get when running ng test locally.

Even though this gives us all the information we need regarding the tests, Azure DevOps has a built-in feature to show tests reports, enabling you to more easily navigate successful/failed tests.

Publishing test results to Azure DevOps

We'll need to publish the test results in a format that can be interpreted by Azure DevOps. In order to understand what formats are supported, lets head over to our build pipeline, and click edit.

On the right side of the build pipeline's edit screen, you should see a list of available tasks. Search for the task named Publish Test Results, and select it.
In the task details screen, you'll see a drop-down for the test result format. You can use any of the available formats, as long as your test runner allows you to export the results in the given format. As Karma supports JUnit, we'll be using that one.

Once added, the yaml configuration will now contain a new section for the PublishTestResults task:

- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/TEST-*.xml'

Ensure this section was added after the step that's running npx ng test, and make the following changes so that it has a displayName, and provide it with a condition so that it publishes test results even when the tests have failed (because we also want to be able to inspect failing tests).

- task: PublishTestResults@2
  condition: succeededOrFailed()
  inputs:
    testResultsFormat: 'JUnit'
    # Make sure you've changed testResultsFiles to the one below 
    testResultsFiles: '**/TESTS-*.xml'
  displayName: 'Publish Test Results'

As we haven't configured our Angular application to publish test results in the JUnit format yet, the build that's being triggered upon saving the above changes will not publish any test results yet.

Configuring Karma to publish JUnit

Install the appropriate reporter for JUnit in the Angular project by running npm install karma-junit-reporter --save-dev.

Update karma.conf.js by including the karma-junit-reporter in the plugins and adding junit as one of the reporters.

module.exports = function (config) {
  config.set({
    ...
    plugins: [
      ...,
      require('karma-junit-reporter')
    ],
    ...,
    reporters: ['progress', 'kjhtml', 'junit'],
    ...
  });
};

That's all we have to change in order to prepare our unit tests to be fully integrated into Azure DevOps. Commit and push the changes you made to the repository.

This should trigger a new build, once that's finished you should see the 3 default tests showing up in the Tests section on the build details (you might need to check the filters, by default it only shows failed tests).

By integrating our tests with Azure DevOps, we have a structured UI for tracking all of our unit tests. Whenever a test fails, we don't have to scroll through the console output on the tests step. Instead, we can inspect the tests altogether and filter to only show those we want.

If we'd have a failing test, we can even click on it to show the details of what went wrong, showing the same information we would get in the console:

Showing Code Coverage in a Build Pipeline

Azure DevOps provides us with the ability to show an overview of the code coverage of our application's unit tests. To do so, just like publishing the test results in a specific format, we'll need to publish the code coverage results in a supported format. Currently, Azure DevOps supports both Cobertura and JaCoCo. Istanbul, the code coverage tool used by the Angular CLI, has support for Cobertura built-in, so we don't need to add any dependency in order to use Cobertura.

We'll need to update the karma configuration to include Cobertura in the reports for the coverageIstanbulReporter:

coverageIstanbulReporter: {
  dir: require('path').join(__dirname, './coverage/ng-azure-devops'),
  reports: ['html', 'lcovonly', 'text-summary', 'cobertura'],
  fixWebpackSourcePaths: true
},

This will generate a file named cobertura-coverage.xml in the ./coverage/ng-azure-devops directory. We will be needing this path in the Build pipeline.

Commit, and push these changes to your repository (this will trigger a build that doesn't publish the code coverage yet), and head over to the build pipeline's configuration on Azure DevOps and add the following step:

- task: PublishCodeCoverageResults@1
  condition: succeededOrFailed()
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Build.SourcesDirectory)/coverage/ng-azure-devops/cobertura-coverage.xml'
  displayName: 'Publish Code Coverage Results'

Just like with publishing the test results, we want to include the code coverage results for failed tests as well. That's why we're setting the condition to succeededOrFailed(). We also need to provide the location of the summary file (created by istanbul), and ensure this aligns with the location of the file, generated by istanbul.

In order to be able to publish the code coverage results, we'll need to run ng test using the --code-coverage flag. Update the corresponding step in the build pipeline configuration to include that flag:

- script: npx ng test --watch=false --codeCoverage=true
  displayName: 'Tests'

Saving the configuration should run a build that, once completed, shows a Code Coverage section on the build's details page.

Publishing the code coverage results will also create a report and make it available as an artifact, attached to your build. If you ever wish to inspect the report, you can download it by opening the Artifacts menu on the upper right corner. Generally, you should find most information on the Code Coverage tab in Azure DevOps itself.

Adding Linting

We can ensure the build pipeline fails when code does not follow the coding guidelines by integrating our linter. Let's add a step to run npx ng lint, either before or after the Build step.

- script: npx ng lint
  displayName: 'Code Analysis'

This will add a basic integration with our linter. Azure DevOps doesn't have a built-in way to keep track of code quality. However, it does have tasks available to integrate 3th party tools such as SonarQube if you would want to integrate with it.

Publishing Artifacts

Now that we have an automated way to verify that the source code compiles, all of the unit tests are running successfully, and code matches with our coding guidelines, we can publish the output of ng build so that we can use it to deploy, either manual or automated.

Add the following step to the end of the Build Pipeline configuration

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: 'dist/ng-azure-devops'
    ArtifactName: 'web-app'
    publishLocation: 'Container'
  displayName: 'Publish Artifacts'

In order to publish the artifacts, we need to provide the PathtoPublish, which is the output folder of the ng build command, an artifact name, and the publishLocation. Providing "Container" as the publishLocation means that it will publish the artifacts as part of the Azure Pipeline itself.

Save the changes, and wait for the build to complete. Once completed, you can download the artifacts from the build result's page:

Every time a build is successful, the latest version will be published as an artifact. This allows us to either download it, or use it in an automated way to deploy our application.

Conclusion

With Azure DevOps, we can easily integrate our Angular application in such a way that we can ensure our codebase is in good health at all times. This should reduce the risk of releasing bugs, resulting in more stable software, and both a happier team, and end-user.

We're also creating our build artifacts in an automated way, reducing time, and complexity, to deploy our application.

In a future article, we'll set up a release pipeline to automatically deploy the build artifacts.

This article was written by Frederik Prijck who is a Software Engineer at This Dot.

You can follow him on Twitter at @frederikprijck.

Need JavaScript consulting, mentoring, or training help? Check out our list of services at This Dot Labs.