Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Create a Build Pipeline for Angular and ASP.NET Core Apps with Visual Studio Team Services

DZone's Guide to

Create a Build Pipeline for Angular and ASP.NET Core Apps with Visual Studio Team Services

If you're a developer of ASP.NET Core applications that make use of Angular, learn how to create a build/release pipeline setup to help you and your team out.

· DevOps Zone ·
Free Resource

Discover how you can reduce your Kubernetes installation from 22 steps to 1.

In this blog post, I want to describe how you can build up a build and release pipeline for your Angular and ASP.NET Core applications using Visual Studio Team Services.

Preparation

First of all, you need a user account with which you can log into <yourname>.visualstudio.com. Then we will need a GitHub repository where your project is checked in. As an example, I will take the repository located at https://github.com/FabianGosebrink/ASPNETCore-Angular-Ngrx. The repository has the client and the server code completely separated, which makes it easy for us to switch technologies or to keep things separated like we will do it with our build and release pipelines in Visual Studio Team Services (VSTS).

GithubRepository

The Server Build for ASP.NET Core

For the server build, we first log into visual studio team services and add a new project.

GithubRepository

We will call this project createBuildPipelinePost and leave all the other fields as they are as this is not about getting your team up to work with VSTS (which you can do) but “only” building a pipeline for your builds and releases. So hitting “Create” and let VSTS create the project should be enough for now.

Next, we will add a new build definition by hitting the New Definition Button and select GitHub then because our project is checked in on GitHub. You can, however, also build projects which are located somewhere else, like BitBucket and so on or even VSTS directly. In this case, we will stick to our GitHub repository and we need to authorize VSTS to access Github for us.

In this case, I authorized my VSTS to access GitHub and I could choose the projects then. I choose the one we mentioned earlier as this is the project we want to run the build on. So we are selecting the master branch here which means that this build pipeline will only listen to that branch. Other branches are not affected.

GithubRepository

The next step you see are prepared build pipelines VSTS holds up for you. You can jump in right away but we will start with an empty process here.

GithubRepository

GithubRepository

VSTS prepared everything here for you which can stay like this. The only thing we have to do is adding new tasks to the build pipeline. The first task we will add is a Nuget task to the first phase. This will install Nuget so that we can do a restore in the second step.

GithubRepository

GithubRepository

I chose version 4.5.1 here. But you can switch between different versions which are around.

I was told that sometimes there are some problems with a Nuget restore command. This is why I choose to restore the nuget packages that way. However, if you have a normal Nuget restore task running you can, of course, use that one instead.

The Nuget restore command now searches for the solution file - which we have in the server folder - and restores the packages. Therefore we set the command to restore and we can name the task accordingly.

GithubRepository

After we created that we can build the whole solution with a dotnet buildcommand. We are adding the task listening on the *.csproj. Important are the arguments we are passing which should set the release --configuration releaseand --no-restore because we already did a restore in the previous task.

GithubRepository

Although we have no tests in this repository at the moment we can add a task for that. My experience is that you are lucky if you have a build pipeline up and running before the project coding starts. It’s always nice to have that thing done and let the server do the heavy lifting of running all tests and stuff. At some point in your project, you’re glad that you built that pipeline up.

So we are using the wildcards to check for specific paths in our application which could be test projects (all Projects within a “Test” folder or a folder with test in its name) and we let them run with dotnet test where the command is the test only.

GithubRepository

One of the last steps is to execute a dotnet publish to get the final results of our build. We can add a new task like we did before just running the dotnet publishcommand. Be aware that we also set the --configuration release again and also as an output we pass the $(build.artifactstagingdirectory) with --output $(build.artifactstagingdirectory). This one gets automatically filled by VSTS. I also like to zip the output which you do not have to do, I just like having one file as an output as this file gets unzipped automatically when it gets released to an Azure web app.

GithubRepository

The last step at the server side is to publish the build artifact so that our release pipeline can actually “see” what was the result out of this build process. We are calling this artifact drop and as a path, we are giving it the $(build.artifactstagingdirectory) because that has been the output in the previous step.

GithubRepository

The Client Build for an Angular CLI

Remember the folder structure in the repository we had was like

Github
└── server
    └── // all server files
└── client
    └── // all client files
├── .github
└── // ... other top level files
...

Until here, we came away with not caring about that because we only have one ASP.NET Core project on it, so we could walk on with the wildcars **/*.csproj for example. For the client side, however, it is better to use the specific paths to point to a specific angular folder created with the CLI.

Let's add a new phase for the client side build and add three tasks to it. Let’s go!

GithubRepository

The first one is an npm install task. Nothing is installed globally as we want our repository being as standalone as possible.

Avoid having a repository where the computer which wants to execute the program has to install dependencies globally to execute your program. Your repo should be like a “black box” if you clone it you do an npm install and it should work. Unfortunately, sometimes you have to and can not do anything about it.

If you add a new npm task it is automatically an install task so you can leave it as is. The only change you have to make is to point the direction to the folder where the package.json lives which is the client folder in our case. You can browse to the repo by hitting the ... button.

GithubRepository

The next npm task is the npm build task. The command is now a custom command. Again the path is the client folder and the command is a run build. In our package.json file we are targetting the output folder .dist/web

 "scripts": {
    // scripts
    "build": "ng build --prod --output-path=\".dist/web\"",
    // more scripts
  },


GithubRepository

Now that we have an output folder now we can also publish that result by publishing it as an artifact. The path to get is now client/.dist/web, as a name we can choose dist and the location should be Visual Studio Team Services/TFS.

GithubRepository

So that's it. We created a pipeline for creating an artifact for the server app which is ASP.NET Core and the client application which is done via the AngularCLI.

But that's not all. Let's do a release taking the artifacts we just created and dropping them to an Azure Web App in this case.

Creating the Release

Preparation

Please log into your Azure Portal and create a new Web App with a name of your choice. In this case, I took “AngularCliOnAzure” but that is really just a sample name. It should be mentioned that behind this runs a real web app on Azure.

Releasing the Server Artifact

To release the server artifact we just created (remember the *.zip-file and the client artifact) we first have to create a new release. So head over to the “Release” tab and hit “New Definition.”

GithubRepository

The template we are going to select is “Azure App Service Deployment,” which we will use to get our artifact and drop it to Azure. This is just an example. You can - maybe should - deploy your client and server code to different servers. That is why we sperated them. In this example we will drop both artifacts to the same server. But I hope you get the idea.

GithubRepository

The first artifact will be the server code. The artifact is a *.zip file we created. So as a source we will select the build definition which produces the artifact as an output.

GithubRepository

As we want to run a deployment everytime a successful build has run we can activate the continuous deployment trigger. Just click on the flash and set the switch to “enabled.”

GithubRepository

If you click on the “1 Phase, 1 Task” link it will redirect you to a page where we can take a closer look at what should be done with the artifact. The general settings can be accessed within the environment tab which is called “Environment 1” in this case. Here we can choose where to put the artifact.

GithubRepository

We can choose the artifact in the task directly. You can either select it by hitting the “…” button or give the path to it. Pay attention to the forward slashes and the name of the CI in front of the particular artifact. So this screenshot shows how to drop the *.zip artifact to the web app on azure. This is our server code. It gets unzipped automatically for us.

GithubRepository

Releasing the Client Artifact

As the second artifact, we have to pick the dist artifact from the client code which gets produced by build phase number two. So we can add another artifact and leave all the settings as is, except the source alias has to be different. We call it “createBuildPipelinePost-CI-client” in this case.

The gray information tab below shows you which artifacts are getting produced, so this is another hint where you can see which artifacts are available.

GithubRepository

The next screen is like the other one before, except we are taking the distartifact which represents our client code now. See that this is not the dist folder we created but the dist (so the name of the) artifact.

GithubRepository

And that is it. Now you should be able to check in something, a build should be triggered automatically and your app should be released to an Azure WebApp. Normally you should receive an email if everything ran smoothly or something went wrong.

Conclusion

Although I personally think that many steps are needed to create a CI/CD (Continuous Integration/Continuous Deployment) pipeline for your apps with VSTS I think that it is very clear what is happening. The steps are well separated and when you create build you have a console output where you can see what is going wrong like it would appear on your console. Also separating the release from the build feels very clean and flexible. After getting into this a bit I am sure I will use it a lot in the future.

Cheers,

Fabian

Download the Kubernetes cheatsheet to learn more about easy it is to run Kubernetes on any infrastructure with Mesosphere DC/OS

Topics:
angular ,asp.net core ,devops ,visual studio ,team services ,pipelines ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}