Part 1: Publish to an Azure DevOps Repository

In this series I’m going to use the free Visual Studio 2017 Community Edition and the free Azure DevOps to target a full-blown CI/CD pipeline to deploy a web application to Azure.  So in addition to those tools make sure you have an Azure subscription. Last, I’ve got the latest Git for Windows installed (v2.19.1.windows.1). So let’s get started after the jump.

Create the Project

Fire up Visual Studio and create a new vanilla ASP.NET Core Web Application called WidgetApi. Then manually add two files in your solution root folder. First, add this .gitignore file that is configured just for Visual Studio. It has no extension so just name the file .gitignore. This prevents files like *.suo or *.user from being checked in. Also add a Readme.md file. Several people have templates like the one I linked to and here’s a good guide to writing one yourself. Your solution folder should look like this:

Now add a Widget.cs POCO class to your project:

namespace WidgetApi
{
    public class Widget
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Shape { get; set; }
    }
}

Rename the ValuesController to WidgetController and return a list of widgets:

using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;

namespace WidgetApi.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class WidgetController : ControllerBase
    {
        [HttpGet]
        public async Task<IActionResult> Get()
        {
            var items = new List<Widget>()
            {
                new Widget { ID = 1, Name = "Cog", Shape = "Square" },
                new Widget { ID = 2, Name = "Gear", Shape = "Round" },
                new Widget { ID = 3, Name = "Sprocket", Shape = "Octagonal" },
                new Widget { ID = 4, Name = "Pinion", Shape = "Triangular" }
            };

            return Ok(items);
        }
    }
}

Note: the code above is missing an await operator and so will run synchronously causing the compiler to generate a helpful warning message at build time. That’s fine. We’ll fix it later in Part 2.

You might also want to change the launchUrl in launchSettings.json to point to api/widget. Now run the app and make sure you get back an HTTP 200 with a list of widgets from the endpoint:

Good to go!

Put Under Source Control

If you look down at lower-right toolbar in Visual Studio you’ll see a helpful button to add the project to source control:

If you click it you should see Git available. (If you don’t check Tools > Options > Source Control and look for it as a plugin. Did you install Git for Windows in the Setup above?) Click Git and when it has finished look at Solution Explorer. Notice that there’s a lock on your files. And look down there at the lower right again. You have two unpushed commits waiting.

In your solution root you now have a new hidden .git folder and Git is tracking your files. So congrats you are now under source control.

Push to Azure DevOps

Before we can build out our CI/CD pipeline we need to push these files to Azure DevOps. Click the small up arrow that shows your 2 unpushed commits and you’ll be taken to Team Explorer. Microsoft wants to make your life easy so they provide a very handy button to push your code into DevOps:

Click that button and authenticate to your account if necessary. Then you can push to  DevOps and have it create a new project for you:

You should not have any trouble with the push unless you were monkeying around with the repo or forced other changes prior to spinning up this project. If you do have trouble and you don’t mind overwriting whatever files are up there you can always configure Visual Studio to permit the Force option. Go into Team Explorer > Settings > Git Global Settings > and check the Enable push –force box. So use the force Luke if you must. But with great power comes great responsibility when you’re working with others. You really want to pull/merge files from other developers. But that’s another topic for another day.

In Part 2 we’ll set up a build pipeline and exercise continuous integration of code changes.