VSTS and Git Integration for Deploying to Azure – Part 3

 

In Part 3 I will cover how to create a Release off of a Build we create from Part 2 https://gregorsuttie.com/2018/08/24/vsts-and-git-integration-for-deploying-to-azure-part-2/

So to create a new Release we click the plus icon as shown below – nothing like consistency in the ui šŸ˜‰

 

So again we get to choose a template this time for our Release Pipeline like so.

After I choose Azure app Service Deployment I get this screen.

Here I get to change the Environment name, so I edited Environment1 to be Development and then I need to select Add next to Artifacts to choose the deployment artifacts (the files i wish to deploy)

 

 

Here I am selecting the artifacts to deploy, I have chosen the Source Type as Build and the Build Pipeline both from part 2 and given the Release pipelineĀ a name and then I click Add.

Now we can choose to setup release based on a number of things, we can make them manual or automated deployments based on triggers etc.

One example is a scheduled trigger and you can set this up by clicking Schedule release trigger as below.

 

With VSTS there are is a tonne of options to try out, its very easy to have either manual builds and manual releases and just as easy to have fully automated build, test deploy pipelines.

VSTS and Git Integration for Deploying to Azure – Part 2

Ok so in this post (part 2) I promised to show you how to use Visual Studio Team Services (VSTS) to build, test and deploy your code to Azure.

Step 1 – Build your code using VSTS

Select Build and Release from inside VSTS like so

On the right hand side click where it says + New and you’ll see the next screen

I have rubbed out the names of the project I the above screen shot in case you’re wondering why it looks weird.

So here I’m saying that I want to use VSTS Git for where my source code belongs, I choose the Team Project, the Repository and which branch I am interested in building, then I select continue.

Now I need to select a template for the type of project I want to build like so.

I have chosen the Azure Web App for ASP.Net and then I click Apply.

On the next screen I need to choose

  • Name for the new Build
  • Which type of pool will I use to build the code
  • Locate the solution file for my project (from a selection)
  • I have chosen my Azure Subscription
  • And I have chosen the App service name from a drop down which comes from my Azure subscription.

 

Above you can see the list of steps which will be preformed

  1. Use Nuget
  2. Restore my Nuget Package(s)
  3. Build the solution
  4. Run any Tests within the solution
  5. Attempt to Deploy the App Service (this step I would normally always remove)
  6. Then VSTS publishes the artifacts to a Drop folder within VSTS which is later used in the Release part of VSTS to deploy the artifacts to Azure in tis case.

I will right click on step 5 and remove the App Service Deploy step as I just want to build my solution and create the deployment artifacts.

 

Ok so now you need to pay attention to this area of the build screen.

The red exclamation mark is showing us we need to fill out some further details before we can proceed, so lets fix this next.

So here we need to add a Branch Filter before it will allow us to Save the new Build.

And now we can either choose Save or Save and queue our new Build, I’ll select Save and queue.

 

And you’ll now see your Build queued.

 

One your build is there you more than likely want to setup continous integration, tick this checkbox inside Trigger.

 

 

 

In the screen above you click Enable Continous Integration and you can fill the screen below out

Join me in Part 3 – And I’ll walk-through deploying the code by creating a Release in VSTS for our new build artifacts.

VSTS and Git Integration for Deploying to Azure – Part 1

At work we use Visual Studio Team Services (VSTS) with git and in this post I’ll walk you through our development process for writing code and deploying it to a demo site on Azure.

I have become a big fan of VSTS, it has some cracking functionality built-in which saves you aĀ lot of time and effort.

I will cover the following:-

Using Visual Studio 2017 with the git integration tools

So I open up Visual Studio 2017 and I first of all need to update my local copy of the master branch and pull down the latest version.

To do this I select Sync as shown above and then I choose fetch to fetch the latest commits and pull to pull them all down as below.


Ok, so now I have the latest codeĀ from the master branch as seen below.

Now I want to run the master branch and see if everything is good and check whats changed with the commits I pulled down but before I can do this I need to apply some local settings.

The reason for this is we have a number of Azure Services being used like event hubs etc and I have a local settings json file with my settings which I never check in. To apply these local settings I saved them into a stash and I will show you how I apply my stashes next.

So I click Stashes within Team Explorer and then I see the following.

 

And now I right-click on local settings and select apply stash, and this will apply my local settings to the project allowing me to run my own event hub instead of the one on our demo site as an example.

In order to get the Git Stash Extension you can download it from Extensions and Updates from the Tools menu within Visual Studio.

 

In Part 2 https://gregorsuttie.com/2018/08/24/vsts-and-git-integration-for-deploying-to-azure-part-2/ – I’ll show you how to use VSTS build pipelines to build and test your code and then deploy it to Azure.

Visual Studio Team Services – Gated Check-ins: How-To

So you using Visual Studio Team Services (VSTS) and you have some build definitions and your team are doing pull requests but you want their branch to run a build before the pull request is reviewed.

The steps to add gated check in are like so:-

  1. Log into VSTS
  2. Go to the Code Menu and then select Branches
  3. From the list of branches look to the right of master for 3 dots … (ellipses)
  4. Click the 3 dots and then select branch policies
  5. Look on the left under Branch policies
  6. Click on Add build Policy
  7. Choose your build pipeline
  8. Fill that out and then give itĀ a name
  9. Make sure it’s enabled
  10. Now when a user goes to create a pull request and pushes they’re code
  11. The gated check-in will check that the users branch builds before anyone can review the pull request.

This add a quality gate to your check-ins using VSTS.

Hope that helps