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 buildbuild 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
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 the Pull request trigger for this article.
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.
Latest comments (13)
Hi, thanks you very much for this post!
I have one question: for example I have several environments (dev, test and prod) and I'm using some 3rd-party services, and for each environment I have different access tokens/secret keys for these 3rd-party services. Currently, in deploy stage I decide which key/token to use and it stored in assets. But the problem that assets is public folder, and it means that every one can see all these keys.
Is there a way to hide them somehow?
Hello, thank you very much for the post. I follow it carefully but still got an error now. What is the runtime stack you chose when you created the web app in Azure Portal? If I choose any version of Node, the option Windows for OS is not available anymore.
Hey, I used the .NET Core run time.
Thank you very much. This saves my day. In fact, I spent the last several days debugging this.
This article really helped me out! I would like to add for people who are looking to use .NET Core with this, I ended up using the Deploy to Azure functionality, but then it becomes kind of a mess using it with the config.json, the reason is it is deploying a .zip file (everything is already packaged).
So in the end, I created this config.json with the file creator in the release pipeline, then SFTP it over after the deployment has finished.
Hello, Thank you very much for this post! I have 1 problem at the release phase. It says succesfull, but if go nagivate to the app service url, I don't my webapplication. Do you know why this is the case?
Hey Murat,
What does the output of the Tasks: Download Artifact (web-app) and Deploy Azure App Service show for the corresponding Release?
"I have an article on how you can implement runtime configuration so you can have different configurations while still using ng build --prod.". Can you please provide me the link.
Sorry I forget adding the link: dev.to/thisdotmedia/runtime-enviro...
Another question I have: I want a test and production environment for my angular project. The test environment should have the artifact deployed based on the command "ng build" and the production environment should have the artifact deployed based on the command "ng build --prod".
What is the best approach for this? I have made for each branch (master/dev) a yaml file, in this file I generate the correct build/artifact. I also have two release pipelines, one listens to builds from dev and one to builds from the production branch based on "Build branch filters" when enabaling "Continuous deployment trigger". After it is triggered, It deploys the right artifact to the right App Service.
Is this a good solution? Because I can't find good information about this. Should I for example use multi-stage build pipeline in order to create both artifacts wheter there are changes to prod or dev branches and have ONE release pipeline with multiple environments which take the correct artifact?
Please help me out with this one, I have been struggling for ages!
As you're deploying from both development and master branch you do have to use 2 separate build pipelines and 2 separate release pipelines. So what you're doing seems right.
However, I'm not sure why you are not using ng build --prod for the development environment. Not using --prod will remove some optimizations done by the ng cli.
I have an article on how you can implement runtime configuration so you can have different configurations while still using ng build --prod.
Hi Frederik, thank you for your response. I'm using "ng build" because I thought this was the way to build your project based on the development configuration. Is it really bad, if so, can you please provide me the article link? : )
Hi Frederik, I solved it by adding the startup command. thanks for your response though!