Like many other .NET developers, I’ve started using the new Visual Studio 2019 version. There are many things to like about this version but one that I wanted to touch on today is the integration between Visual Studio and Azure DevOps. This integration makes it ridiculously easy to create a project in Visual Studio and setup a pipeline for building and deploying that project anytime you make a change to the underlying source code.
Let’s spend a few minutes going through the steps needed to setup a complete CI pipeline between a local Visual Studio 2019 project and a live Azure server environment. I promise, it will be easier than you might imagine.
When we’re done we’ll have a complete CI pipeline for a .NET Core based REST service hosted on an Azure server with a source control repository to track changes and kick off builds as we need them.
To start, we’ll need at least 3 things:
- A copy of Visual Studio 2019 installed on your PC or MAC.
- An Azure account that you can login into.
- A source control account, somewhere. You can use almost anything but I’ll be using GITHUB for this walk through.
If you aren’t already using Visual Studio 2019 then you’ll need to download. Just click this link to get started:
You may download any version of Visual Studio 2019 you like for this walk through. Note that the community edition is completely free.
Next, we’ll need an Azure account. If you have one already then use that. Otherwise, click on this link to create a trial account that you can use to complete this walk through:
Now that we have Visual Studio 2019 and an Azure account, we only need a source control service. I’ll let you decide what flavor of source control you like best. I personally like GITHUB and here is a link to get started there:
At this point I’ll assume you’ve taken the steps to install Visual Studio 2019 on your computer. I’ll also assume you have access to an Azure account and a source control account.
Let’s get started!
I usually start a new project in Visual Studio first. The opening screen for Visual Studio 2019 looks like this:
We’ll want to choose the ‘Create a new project’ option, to get started.
Once we do that, the next screen shows up, which let’s us choose a project type:
For our walk through we’ll choose the ASP.NET Core Web Application project type. Click the next button, which then shows this screen:
Choose a name and a location for your project, then click the create button. That shows the next screen:
For this walk through, we just want to create a simple REST service, so, choose the API option and click the create button.
Once you’ve done that you should see a project that looks similar to this one:
This is a complete REST service with a fully functional ‘Values’ controller that we’ll use, later, to verify that our build pipeline has deployed our service to Azure.
For now, we just need to connect our new project with a source control service. Assuming you chose GITHUB like I did, that means we’ll need to go create a new repository for our project now by navigating to the GITHUB site.
I won’t try to teach GITHUB here, but quickly, I usually create a new repository by clicking this pretty green ‘Create’ button, on the GITHUB site:
That usually takes me to another screen where I enter the repository name before I click another pretty green ‘Create’ button.
That results in an empty GITHUB repository, where we’re about to add the code for our project. Next, go find the url for this page in the browser and copy it to the clipboard.
So, at this point you should have a URL, copied from your browser, on your clipboard, that looks something like this:
That’s what we’ll need next, when we switch back to Visual Studio 2019, and click the link at the bottom of the screen, for source control:
Clicking that shows us a GITHIB popup, in Visual Studio. Clicking that popup show us this screen:
For this walk through I chose to use GITHUB for a source code repository. For that reason, we’ll need to click the lower button on this screen. Once we do that, it displays an area where we can paste that URL that’s been sitting on our clipboard. Do that now:
After you’ve supplied the url to your repository, press the ‘Publish’ button to publish your Visual Studio 2019 project to GITHUB.
To prove to yourself that you actually published your project to GITHUB, go back to that site now and refresh the page on your browser. You should see something that looks like this:
From here, we need to take steps to wire our GITHUB repository to an Azure CI pipeline. For that, we need to go back into Visual Studio 2019. If the ‘Solution Explorer’ tab is not visible in Visual Studio then go to the View | Solution Explorer menu to make that visible.
Next, right click on the solution name, in the Solution Explorer, in Visual Studio, and choose the ‘Configure Continuous Delivery to Azure…’ menu choice:
That should bring up the next screen, which allows you to enter the information required to make the connection between GIHUB and Azure:
Most of the screen is already fill out. But, there is one section where we need a special digital key for our source control service. That key is called a ‘PAT’ and the screen shows us where to go, to get a PAT, if we need one. So, if we have a PAT we can enter it now. If we don’t have a PAT we can follow the highlighted link and get one from GITHUB. After we fill in the PAT, we press the OK button to finish the operation.
Most people following this walk through won’t already have a GITHUB PAT, so, let’s follow that link now and see how to generate one. Clicking that link takes us to GITHUB, on a screen that looks like this:
Here you’ll need to supply a name for your PAT. Also, you’ll need to ensure that you check the ‘repo’ and ‘notifications’ sections, for the key. After that, there’s a big green ‘Generate’ button at the bottom of the page (not visible in the screen shot), scroll down to that button and press it.
Once that’s done, you’ll be shown a screen that looks like this:
Your new PAT will show up here, along with any other PAT’s you may already have created. An important point here is that this new token is PRIVATE and you shouldn’t show it to ANYONE. Also, once you leave this screen you’ll never see this value again, which means if you’ll need it later then you should copy it someplace safe now. You can’t ever get back to see this PAT value, once you leave.
Copy your new PAT to your clipboard by clicking on the little clipboard icon, then let’s move back over to Visual Studio.
Paste your PAT from the clipboard into the place shown in the screenshot above, then click the OK button to finish. That’s it! We’ve done everything required to create out CI pipeline!
At this point, the next thing we’ll need to do is go into our Azure portal. If you don’t remember where your portal is, here is a link that should work:
We’ll need to work with Azure DevOps, so, we’ll need to make sure we have a handy link to that portion of the portal. To do that, first click the ‘All services’ link, which will show a list of all the Azure services. From there, click the ‘DevOps’ link, which will show a list of all the services related to DevOps. We will be interested in the ‘DevOps Projects’ and ‘Azure DevOps’ portions, so, click the little start next to those. Once you do that, you’ll see ‘DevOps Projects’ and ‘Azure DevOps’ at the left of your Azure portal, and you won’t need to go through this again to get there.
We’ll need to start with Azure DevOps, so click that link on the left of your Azure portal now. Once there, you should see this screen:
If this is the first time you’ve used this screen then you might need to click the ‘My Azure DevOps Organizations’ link, as show in the above screenshot.
From there, you’ll go to this screen, which will show you all your DevOps projects:
Clicking on your project will take you to this screen, where you can see that Azure tried to perform a build for you, already.
Only thing is, if you look closely, there is a red X next to the project. That’s never a good sign … Clicking on the build takes you to this screen:
Eeek! We have an error in our build already! Now, I have to admit, this threw me off a bit. I didn’t expect a build error in the project considering we haven’t yet done anything with it. Still, these things happen, I suppose …
From here I had to do a bit of Googling and I discovered that there’s a setting we need to turn off in the build tasks. So, to do that, we need to go back to the previous screen (hit your browser back button) and find the edit button after our pipeline:
Clicking that button takes us to a screen that allows us to edit the pipeline itself, which is exactly what we need.
Once the screen above is shown, click the Publish icon, in order to edit the publishing steps. That will take us to this screen:
On this screen, make sure the ‘Publish Web Projects’ step is NOT checked, then press the ‘Save and Queue’ button, at the top of the screen. We want to cause another build here, so we can prove to ourselves that what we did just fixed the build problem. Once we click the ‘Save and Queue’ button it will show us this screen:
Just press the pretty blue ‘Save and Queue’ button again, to start the actual build.
Now, click the ‘Builds’ link at the left of the page to see our current list of builds, which should look something like this:
As we see, there is the original, failed build in the list. Above it though is a new build. That’s the build we are interested in, now. Click that build and we can watch it in action. It should look something like this:
As we can see, the publishing portion of the build now works. So what was the error that we had to manually fix? As near as I can tell, the Azure deploy task is assuming something about our project that isn’t correct and is trying to find either a web.config file, or a wwwroot folder to deploy. Now, I’m not sure why it can’t find the wwwroot folder, since it’s there, but, whatever the case, go through the steps I just showed you and it shouldn’t matter after that.
So, where are we? Well, we’ve created a .NET Core REST project in Visual Studio, we created a GITHUB repository to track the source code for that project, then we connected Visual Studio to that repository so they could work together to track any future project changes. Then, finally, we created an Azure DevOps CI pipeline to watch that GITHUB repository for changes and automatically build that project and deploy it to Azure for us.
How do we know our REST project is in Azure? I mean, the build says it deployed it, but, how can we prove that to ourselves? The easiest way to do that is to navigate back to the home screen for our Azure portal. Remember, that link is here:
Once there, look for the ‘App Services’ link, on the left hand side of the screen:
Clicking that takes us to this screen:
Here we see a list of all the services we have published in Azure. Clicking the link for our project will take us to a very detailed page that look something like this:
In the upper right hand portion of that page is a url. That is the url for our REST service, where our CI pipeline deployed it on our last build. If you copy that url to your clipboard and fire up your browser you’ll see this:
That’s because, if you recall, we never added a ‘home’ page for our REST project, so it should show a 404 since it’s not there. But, from here we can modify the url by adding ‘/api/values’ to it, and when we do that, we’ll see this:
Huzzah! That’s the output from our REST service, hosted LIVE on Azure! Not only that, but we have a repeatable build process that will updated that service every time we checkin our changes to GITHUB, and we don’t even have to bother with making that happen ourselves.
Pretty cool, huh?
Now, I should mention that parts of Azure aren’t free, and hosting your REST service there indefinitely might actually cost you some money. The good news is, Azure has a free trial that comes complete with something like $150.00 USD credit, for playing around with things like what we just did. So, feel free to go through these steps but understand that you’ll want to take responsibility for managing your Azure account to ensure you don’t spend more than you wanted to.
Also, the REST project we published doesn’t have any kind of security to it, nor does it enforce any kind of policies for preventing DOS attacks, or anything like that. It’s just an out of the box Visual Studio REST project. I used an out of the box REST project to demonstrate how easy it is to wire up ANY kind of web project to an Azure CI pipeline. But, if you intend to keep this service published on your Azure portal then you’ll want to add security and take steps to harden it, to protected it from all the craziness that happens on the Internet.
There you have it. A handful of quick steps and you have a functional, repeatable build process. Congratulate yourself, because, sadly, having a repeatable build process places your organization in a rather elite group …
This pipeline could easily be modified in any number of different ways. I just took a happy path for demonstration purposes. So, if you need a quick CI pipeline then dive in and don’t be afraid to customize things to match the needs of your organization.
I hope you enjoyed the article.