Continually Deploy an Angular Project to Azure with Visual Studio Team Services CI/CD

Share this video with your friends

Social Share Links

Send Tweet
Published 6 years ago
Updated 5 years ago

Having a Continuous Integration and Continuous Delivery Pipeline for your applications is one of the most important things when working on small as well as large projects. In this course you will learn how to set up a build of an AngularCLI project with Visual Studio Team Services and release it to an existing Azure Web App in the end.

Get your first free Azure subscription here: https://azure.microsoft.com/de-de/free/

Instructor: [00:00] In this course, we want to build a continuous integration and continuous delivery or CI/CD pipeline for an angular app created with the Angular CLI which is checked in on GitHub over Visual Studio Team Services and deployed on Azure.

[00:16] For this course, I prepare three things. First, I created a new web app in Azure which is called Angular CLI on Azure, and can be reached via Angular CLI on azure.azurewebsites.net. As you can see, the app service is completely new when it is running.

[00:33] Next in our Angular CLI project, I introduced a new npm task called build prod which triggers a production build. In the dist folder which gets created by the Angular CLI, we can see our output in a specific folder for our project.

[00:53] Lastly, I hosted dist project on GitHub as a repository. Now, we want to create a CI/CD pipeline to execute a build that it change on the master branch. Every time we check something into the master branch, or a branch of your choice, new version should be deployed to Azure.

[01:10] For that, let's switch over to a visual studio portal which is reachable on their yourname.visualstudio.com. In my case, this is fabiangosebrink.visualstudio.com. There we can create a new project. Let's call it Angular CLI on Azure and click create.

[01:29] After this is ready, we can hit the build tab and create a new build pipeline. As a source, we can select GitHub as our project lies on GitHub. Of course, you can select every other source as well. You can use Git and lay the code inside your visualstudio.com account as well for instance. However, for this demo, we choose GitHub as a source.

[01:58] We just keep the name for the sake of simplicity and authorize VSTS against GitHub with all as in this case. Having done that, we can select a repository egghead deploying in Angular CLI project to Azure with VSTS. We select the master branch for the one to trigger the whole pipeline.

[02:23] If we hit continue, we can select different templates for our build. Let's start with an empty process. As a name, VSTS took Angular CLI on azure-ci first, which we can leave like this, and we can add a new task hitting the plus button to the face, face one in this case.

[02:49] We can search for npm and add an npm task in the first place which is doing an npm install by default. This is exactly what we need right now. The working folder with a package.json can be left empty, because we are already in the root of our application.

[03:06] If you have to navigate into specific folders into your project, you can do that here. To add the second task, we hit the plus button again, and again search for npm, adding the same task. This time we want to execute the build command who introduced. We will rename the task and choose custom in that drop down.

[03:32] The command and arguments is run build prod in this case. We can save that. If we do a build like this, we know that a dist folder gets created by the Angular CLI by default. This can be the artifact which we want to provide or release pipeline which we go to in the next minutes.

[03:55] Before we can access that, we have to publish this build artifact with another task. We can choose after hitting the plus button again. This time we are searching for publish. If you scroll down a little, you can see a task "Publish Build Artifacts". Just add that one to the build process, and now let's modify it a little.

[04:23] The path to publish, as we are still in the root of our project and the dist folder will be created right here during the build, we can simply choose the dist folder as the path to publish. Let's rename the artifact name to "dist" as well and save again. VSTS automatically renames the dist by name for us.

[04:44] In the control options and output variables, you can specify even more things, but for this demo, this should be it. Now, we can start the build process hitting the queue button. Leaving everything like it is, and hit queue again.

[04:59] You can see build 335 has been queued, and we can see that it is running. VSTS now waits one agent which is free and sets up everything for us like we just configured it. If it's ready, you can see several summaries of our build and in the artifacts tab, you can see the build artifacts which have been created.

[05:20] In our case, this is a dist folder with the project folder in it. As the last thing here, we can set up continuous integration by editing the build process hitting triggers and unable the check box, unable continuous integration.

[05:42] Now, every time the master branch has a new check in, this build gets triggered. Now, let's try to release of the created artifact hitting the release tab on the left. Here, we can select the Azure App Service deployment template as we want to deploy to an Azure App Service which we created as a preparation for this course in the beginning.

[06:04] As an artifact, we can add the one we just created from the build hitting. Add an artifact, then build, and select the build pipeline Angular CLI on azure-ci in this case. We can rename the alias just as the source itself and in the info box below, we can already see that this pipeline created an artifact called dist.

[06:29] That's great. Let's use that one. We are hitting at, and of course beside a continuous build, we also want to have a continuous deploy. We can add the continuous deployment trigger for the release too. Just hit the flash button and enable the continuous deployment trigger.

[06:51] Next, we can enter the faces and tasks, and see the environment with one task which already got created for us. In the environment, let's fill in the Azure subscription or app services running on, and choose the app service name which is Angular CLI on Azure in this case.

[07:16] In the task, deploy Azure App Service. Many things that filled are the ready, but we have to pay attention to the text box, package or folder, which we have to point to the folder of the artifact which got created.

[07:28] This is the name of the Angular CLI project in this case to set the button with the three dots and select the proper folder. Again, you can add a lot more to the release like creating a web config, add additional deployment options etc. For this demo, it's OK like that.

[07:51] If you hit release and create, a new release gets triggered. As you can see release, one has been created. If we take a look at it, the agent is going to be picked and the release is executed with this agent. If that succeeded, we can go back to our running app service and hit refresh.

[08:16] Now, we can see how Angular CLI project got released to Azure. Great. Now, let's check if the CI/CD works by changing something on the code. In the app.component.ts, I will change the title to "Hello VSTS and Azure."

[08:43] Close all files and check this directly into master which it shouldn't never do normally. Back in the build tab of visualstudio.com, you can see that build 336 has been triggered automatically. If we hit release, a new release release two has been triggered to.

[09:21] After this one was successful, we can go back to our web app on Azure, hit refresh again, and see the changes. We made changes to our app locally, check that in on GitHub, build, and deployed it over Visual Studio Team Services, and just did a release on Azure.

egghead
egghead
~ 15 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today