{"componentChunkName":"component---src-templates-tags-js","path":"/tags/VSTS/","result":{"data":{"allMarkdownRemark":{"totalCount":2,"edges":[{"node":{"id":"f9ff0245-c07a-563a-8cf3-e72f29d0cffb","html":"

In my previous post I showed you how to setup a build pipeline for a SPA application written in Angular using Angular CLI and ASP.Net Core as back-end. I promised back then to continue with the release as well, but have been pretty busy lately.

\n\n

Now is the time to pay my debt and show you how you will get the release done to make it a proper continuous delivery right from when you commit the code to when it is deployed to production.

\n

We will be using Azure Web Apps for our deployment purposes but it really doesn’t matter where you deploy it since there are many third party tools covering different providers like AWS.

\n

Create the release definition

\n

You can create a release in VSTS in two easy ways, either click on the release tab and create a new release definition:

\n

\n \n \n \n \n

\n

or if you have a successful build click on the release button next to it and it will then brings you to the same page but automatically links it to the build definition’s output artefact:

\n

\n \n \n \n \n

\n

The easiest way to create the release definition is based on a template. The best template for our purpose is Azure App Service Deployment, which is very straightforward to use. When you click on create new release definition you will see below pop up:

\n

\n \n \n \n \n

\n

Enter the name and close the panel by clicking on the x mark (there is no save button here).

\n

Linking the build artefact

\n

Now it is time to add the build artefact to the release. Click on add artefact button and you will see below pop up:

\n

\n \n \n \n \n

\n

Then select Web App from the app type drop down and select the web app you created from step one above.

\n
Note: Run on agent in this page uses VS2017 hosted agent, if you want to use a Linux host you will need to change the settings yourself.
\n

Now click on the Deploy Azure App Service task to see the details on the right hand side panel. We will leave the version on this page to remain on 3.* which now supports Supports File Transformations (XDT) and Supports Variable Substitutions(XML, JSON) but if you want to use an older version you can do that.

\n

\n \n \n \n \n

\n

Based on what you’ve selected in the environment section from previous steps, the next three fields will be pre-filled for you.

\n

The next important thing to consider is when you have set up an staging slot for your web app and want to deploy to it first and do some verification before deploying to production which is a logical precaution. If so tick the deploy to staging box.

\n

\n \n \n \n \n

\n

You can leave the package folder intact if the build output is created on the default working folder.

\n

Select the take app offline if you haven’t selected the deploy to slot option (since users might experience some unexpected behaviour if they are using the application).

\n

And at last if you want to use web deploy for reasons like having a dependency on it, you will need to tick publish using web deploy and that’s it.

\n

Click save and queue release if you already have a successful build and there you go, end to end from commit to deployment to the target environment.

\n

Hope this helps you to have a seamless experience using Visual Studio Team Services features for CI/CD.

","timeToRead":3,"frontmatter":{"title":"Setting up VSTS CI/CD for a SPA app using AngularCLI, ASPNetCore (Part 2)","unformattedDate":"2017-12-18T00:00:00.000Z","date":"Dec 18, 2017","path":"setting-up-vsts-ci-cd-for-a-spa-app-using-angularcli-aspnetcore-part-2/","author":"Yaser Adel Mehraban","tags":["angular","aspnetcore","CI/CI","visual studio","VSTS"],"thumbnail":{"childImageSharp":{"gatsbyImageData":{"layout":"constrained","placeholder":{"fallback":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAJABQDASIAAhEBAxEB/8QAFwABAQEBAAAAAAAAAAAAAAAABAABAv/EABcBAAMBAAAAAAAAAAAAAAAAAAABAgP/2gAMAwEAAhADEAAAAXt70o8ieX//xAAaEAACAgMAAAAAAAAAAAAAAAACAwABICIj/9oACAEBAAEFAgBlN2nXD//EABcRAAMBAAAAAAAAAAAAAAAAAAACEmH/2gAIAQMBAT8BZqJ0/8QAFREBAQAAAAAAAAAAAAAAAAAAABH/2gAIAQIBAT8BV//EABoQAAEFAQAAAAAAAAAAAAAAABEQICExQnH/2gAIAQEABj8Ck9Npln//xAAbEAACAgMBAAAAAAAAAAAAAAABEQAhIFFh8P/aAAgBAQABPyF5JQ2VNILFgcnm8P/aAAwDAQACAAMAAAAQoz//xAAXEQEBAQEAAAAAAAAAAAAAAAABABFx/9oACAEDAQE/EEWt2v/EABcRAAMBAAAAAAAAAAAAAAAAAAABIXH/2gAIAQIBAT8QUMo//8QAHhAAAgEDBQAAAAAAAAAAAAAAAREAITFBEFFxodH/2gAIAQEAAT8QEHubgJaJ4p3DF8BsdvYE3cmiZ1//2Q=="},"backgroundColor":"transparent","images":{"fallback":{"src":"/static/fb4319d21614a974df93be566aac2446/351b6/vstsazure.jpg","srcSet":"/static/fb4319d21614a974df93be566aac2446/37781/vstsazure.jpg 750w,\n/static/fb4319d21614a974df93be566aac2446/351b6/vstsazure.jpg 800w","sizes":"(min-width: 800px) 800px, 100vw"},"sources":[{"srcSet":"/static/fb4319d21614a974df93be566aac2446/0f892/vstsazure.webp 750w,\n/static/fb4319d21614a974df93be566aac2446/1b807/vstsazure.webp 800w","type":"image/webp","sizes":"(min-width: 800px) 800px, 100vw"}]},"width":800,"height":348}}}}}},{"node":{"id":"467edae9-dac5-51be-a369-328074ecbddb","html":"

Recently I was assigned to a green field project where we had to create an initial structure of a project which was going to be written in Angular 2 using Angular CLI for front end side and ASP.Net Core for back-end.

\n\n

We had to use VSTS (Visual Studio Team Services) as our source control and build and deployment pipeline. The result was then deployed to Azure Web Apps and the aim was to make this happen.

\n

After some digging and trying the new version of Visual Studio 2017 and setting the initial build steps, I found out that VSTS does not support the csproj files yet. Therefore, I had to go back and use visual studio 2015 with project.json file.

\n

On the other hand since we were using Angular CLI we couldn’t merge it easily in one project with our ASP.Net Core project since it hides the actual webpack config file.

\n

At least it wasn’t something we could do quickly and we had to prepare a POC to get a taste of what was going to happen in the product.

\n

So I started googling and found a good article from Jürgen Gutsch showing how to simply merge them using two different projects and a simple front end build before building the web app.

\n

I won’t go into too much details here, but basically you would build the Angular project and modify the config to write the output files into wwwroot folder. Yes I know, simple.

\n

\n \n \n \n \n

\n

That done, I started to setup the VSTS build steps. Well that is very straight forward, you just have to give the steps the right order so start by create an empty build.

\n

1. Get the source code

\n

The very first step is to get the source from source control. Define your repository and the branch you are working on.

\n

\n \n \n \n \n

\n

2. Restore dot net packages

\n

Add a command line task and name it restore (you can call it something else this is just to make each step clear). Then type dotnet in the tool text box and restore in the arguments.

\n

\n \n \n \n \n

\n

3. Versioning if intended

\n

If you care about versioning this is the time for it. What we chose to follow was SemVer so we put the major and minor numbers in project.json and got the rest from date and revision.

\n

Then all we had to do was to create a PowerShell script which extracted those and put them together to form the complete version and set it in project.json and AssemblyInfo files.

\n

The PowerShell script would as simple as:

\n`, `32854390095898900000`)\"\n >\n \n Copy\n \n \n
Write-Output \"Getting version from Build number\"\r\n\r\n$jsonpath = \"$Env:WebSourceFolder\\project.json\"\r\n$json = Get-Content -Path $jsonpath -Raw | ConvertFrom-Json -ErrorAction Ignore\r\n\r\n$BuildVersion = [regex]::matches($Env:BUILD_BUILDNUMBER, \"\\d+\\.\\d+\")\r\n\r\nWrite-Output \"Build Version extracted =&gt; $BuildVersion\"\r\n\r\n$Version = $json.version + \".\" + $BuildVersion\r\n\r\nWrite-Output \"App Version constructed =&gt; $Version\"\r\n\r\n$json.version = $Version\r\n\r\n$json | ConvertTo-Json -depth 100 | Out-File $jsonpath\r\n\r\nWrite-Output \"Applied Version\"</pre>
\n

4. Run the versioning script in build

\n

As you can see we are extracting the major and minor from project.json and date and revision from build number. In order to set that in the first place you need to define the build output format as follow in the options tab of the build:

\n\n \n Copy\n \n \n
$(BuildDefinitionName)_$(Year:yy)$(DayOfYear)$(rev:.rr)
\n

Now you can create a PowerShell task and run this script and name it versioning. Leave the type to “File Path” and write the script path inside its box.

\n

\n \n \n \n \n

\n

5. Building the solution

\n

Time to build the solution. Create a “Visual Studio Build” task and write the solution file’s path (leave it as default which usually works), then $(BuildPlatform) in the platform box. Don’t forget to change the Visual Studio version to 2015, otherwise your build will fail.

\n

\n \n \n \n \n

\n

7. Run JS tests

\n

If you have any JS tests this is the time to run them. By default the Angular CLI is setup in a way that the tests can be executed using npm test command. So create another npm task and call it “run js tests”.

\n

The only thing to remember is that you have to set the working folder (I am using build variables but you can fully type that) correct, this is where you specify your Angular project root folder. Now the only thing left is to write test in the command box.

\n

\n \n \n \n \n

\n

8. Build the client application

\n

Time has come to build the Angular project. This can be done by running another npm task. You just have to make sure that you have already defined the ng command to run Angular CLI.

\n

All you need to do now is to type run as command and then “ng build” as argument. This step is the key since it will build the client project, bundle everything and copy them into wwwroot folder of the web project.

\n

\n \n \n \n \n

\n

9. Run server side tests

\n

Almost there. This is the time to run your server side tests. You can do that by creating a Visual Studio Test task. Default values will suffice unless you might want to customise them.

\n

\n \n \n \n \n

\n

10. Publish the web project

\n

Although these steps might seems a lot to do, they are pretty straight forward. Time to pack and create a publish artifact. First you will need to run dotnet publish from root of your ASP.Net Core app.

\n

To do this you need a command line task. You can pass your build configuration and publish directory to this command as well. I’ve done this as build variables.

\n

\n \n \n \n \n

\n

Done. Now you can proceed with creating the release. I will explain that in my next post so keep an eye out.

\n

Also any comment or improvements are very appreciated.

","timeToRead":4,"frontmatter":{"title":"Setting up VSTS CI/CD for a SPA app using AngularCLI, ASPNetCore (Part 1)","unformattedDate":"2017-04-27T00:00:00.000Z","date":"Apr 27, 2017","path":"vsts-cicd-angularcli-aspnetcore","author":"Yaser Adel Mehraban","tags":["angular 2","angular cli","aspnetcore","CI/CI","VSTS"],"thumbnail":null}}}]}},"pageContext":{"tag":"VSTS"}},"staticQueryHashes":[],"slicesMap":{}}