Forem: Nicole Stevens

Running MacOS on Windows 10 with WSL2, KVM and QEMU

Nicole Stevens — Thu, 06 Aug 2020 10:01:20 +0000

Note - Unfortunately this no longer works due to movement in the WSL offering for Windows 11 Dev Channel. Am leaving this here incase some of the workarounds for issues below help others in their projects!

I needed to record a demo on a Mac, I don't own a Mac and was contemplating borrowing one from a friend. Then I realised, I finally had an excuse to give this a go! I've been itching to since I read - Accelerated KVM guests on WSL 2, an awesome write-up on how to run accelerated KVM guests on WSL2 from @unixterminal

This is a walkthrough of how I used the excellent work of @unixterminal and @FoxletFox and got my 3 year old XPS Intel i7 to run MacOS on Windows 10! Without their writeups and scripting this post probably wouldn't exist.
I am still stunned how good the performance is having run through this! I've tried a couple of other Linux distro's too, seriously slick.

Before starting check out the requirements from the top of the "Accelerated KVM guests on WSL2" post. One thing that's not obvious is your CPU needs to support virtualisation. Unless you're running an Intel CPU from the early 2000s or even earlier you should be OK. If your CPU does support virtualization it might not be enabled in your BIOS, it's worth a check before you start. If you're already running a hypervisor, it's likely this is good to go.

You'll also need to be running a windows insider build of Windows 10. The insiders Fast ring which is mentioned in the pre-requisites is now the Dev channel. One of the features required didn't come into Windows 10 until build 19619 and the nested virtualisation support for AMD didn't come in until build 19636 either, so that's a must if you are on AMD too. The windows insider page currently lists 19042.423 as the highest build available in Beta and 19041.423 as Release Preview, so for the moment this will not work correctly without using the Dev channel.

The insider channel renaming is described here. Dev channel is described as Ideal for highly technical users. Insiders in the Dev Channel will receive builds that is earliest in a development cycle and will contain the latest work-in-progress code from our engineers. These builds will have rough edges and some instability that could block key activities or require workarounds.

With this in mind, think twice about running the Dev channel on your main machine, or if you wouldn't consider yourself a highly technical user! If you're OK with that, dive right in :

Follow the steps in "Accelerated KVM guests on WSL2" until you reach the section titled Important note about building a module in WSL: Time was fairly tight for getting this up and running, I wasn't going to be tweaking performance and I didn't want to keep loading the KVM for Intel module manually, so:

KVM for Intel processors was selected as above, note that the AMD selection is below it.

Carry on from "Exit the Virtualization" paragraph until you get to this command:



 kvm-ok

If you've followed the steps carefully and hit all the pre-reqs when you execute kvm-ok you should see:



INFO: /dev/kvm exists
KVM acceleration can be used

If not you are likely to see:



INFO: Your CPU does not support KVM extensions
KVM acceleration can NOT be used

If you are seeing the above you are definitely running a Windows 10 Dev channel, run back through the steps once more, you might have missed something.

Check nested KVM is OK

If you're getting "KVM acceleration can be used" you can proceed with the steps in the post.

The next steps is:



cat /sys/module/kvm_intel/parameters/nested

When executing this command N was being returned. Having traced back through the steps it was time for a search which yielded an issue from the WSL github repo. So reverting back to the step Install your kernel in WSL 2 and enable nested KVM the .wslconfig was changed to:



nestedVirtualization=true
kernel=C:\\Users\\<username>\\bzImage
debugConsole=true
pageReporting=true
kernelCommandLine=intel_iommu=on iommu=pt kvm.ignore_msrs=1 kvm-intel.nested=1 kvm-intel.ept=1 kvm-intel.emulate_invalid_guest_state=0 kvm-intel.enable_shadow_vmcs=1 kvm-intel.enable_apicv=1

You'll need to restart WSL once more and check the command once more.

Note the command line args are almost identical to those added to kvm_intel.conf, I haven't investigated why the nested setting isn't picked up from the conf file.

Also note that setting debugConsole opens up the WSL debug console, you can turn this and pageReporting off later by removing them from the .wslconfig file and restarting WSL. I left it in for a while in case I needed to troubleshoot further.

The check for nested KVM now returned a Y as required:



cat /sys/module/kvm_intel/parameters/nested
Y

Config X for WSL2.

Having run a far few X servers in the past I just wanted something that just worked without a lot of setup. Therefore, I went for X410 which is £9ish in the Microsoft store, but as I'm planning to use this until GUI support comes out later in the year, it was worth the price for the easy setup.

Install as normal in the store then add the environment variable in the steps to your .bashrc:



cd ~
nano .bashrc

Once nested KVM is up and running and you've configured WSL to send X output to windows, you are ready to try a distro. If you keep following the post at this point you'll set up an Ubuntu 20.10 daily build. I ran through this as a check to see if everything was working, the steps for this were exactly the same as in the post.

Setup for MacOS VM

The MacOS-Simple-KVM GitHub repo is linked from the original post. It is described as "set up a simple macOS VM in QEMU, accelerated by KVM." If you ran through setting up the Ubuntu 20.10 daily build in step 4 you'll already have seen QEMU being mentioned. You might be thinking, why are there two types of virtualization technologies? The key part is in how KVM and QEMU differ, which is summed up nicely in this post. KVM uses the CPU virtualization extensions for Intel and AMD, and QEMU is performing the virtual hardware emulation, or to put it another way, KVM is QEMU's "go faster stripes"!

The steps were followed as listed but with the following tweaks. First clone the git repo in, make sure to use the linux filesystem as it is faster at the moment on wsl2 than windows (/mnt).

This walkthrough is using Ubuntu so it's the top line to install QEMU, Python and Pip if you haven't already got them:



sudo apt-get install qemu-system qemu-utils python3 python3-pip

Run jumpstart.sh to fetch the MacOS media of your choice:



./jumpstart.sh --mojave

I also went with Mojave.

Now create a hard disk, I went with 32GB, I wanted to try and go a little lower but on investigation I found some issues logged where less than 32GB looked to be creating issues for other users:



qemu-img create -f qcow2 MacOS.qcow2 32G

Note I've changed the name of my disk, by this point I had a few VM's setup so wanted to make it more obvious!

Edit basic.sh to add the VM disk into the VM :



    -drive id=SystemDisk,if=none,file=MacOS.qcow2 \
    -device ide-hd,bus=sata.4,drive=SystemDisk \

Now make sure the X server from step 4 is running as QEMU will try and use graphics mode by default. If it isn't running when you run basic.sh in this next step it'll have for a minute or so then fail:



./basic.sh

The VM boots but there are some errors:

The top section boxed in red is caused by the -cpu line in basic.sh. The standard settings in the basic.sh file are sending instructions around performance enhanced features to the host CPU which it cannot understand. The box in green are errors related to sound, I'm not so worried about those, and explain my sound related issues with Ubuntu above. You can edit basic.sh further to straighten these out, but the VM still booted with these errors present.

The VM boots to the Clover boot manager, where you can use your keyboard to hit return (no mouse at this point) and "Boot macOS Install from macOS Base System" will begin:

The macOS utilities screen is now displayed and you should have mouse support. If your mouse pointer is out of synchronisation with the one on the VM you will need to adjust the settings in the basic.sh file. Shut the VM down using the apple icon top left and edit basic.sh in nano once more:

The usb device line needs to be altered from usb-mouse to usb-tablet. Run basic.sh once more and your mouse should now align.

As mentioned in the steps from the macOS-Simple-KVM instructions, you need to partition the disk first. If you enter Disk Utility, find your QEMU HARDDISK from the left hand menu and Erase it and partition it.

You can now return back to the macOS Utilities menu and choose Reinstall macOS, from here it is the same as a standard reinstall, this does take quite a while! No further tweaks were required from this point on:

You can move in and out of fullscreen with ctrl+alt+backspace and remove the VM banner with "Machine View" at the top with ctrl+alt+F.

If you now leave your setup as-is with no further tweaks you will be sent into the Clover bootloader each time you reboot or run your VM:

I've got a few more options to choose from than you will have as I'd been playing around with things before I took this. The key thing is you need to use the arrow keys to choose "Boot macOS from macOS", this will boot your install and you are good to go!

Windows Terminal - port a scheme from iTerm2, customise your own scheme and use a custom font

Nicole Stevens — Wed, 20 May 2020 19:09:55 +0000

Introduction

Windows Terminal 1.0 was released at Microsoft Build 2020. There are docs on how to customise your theme and sites to download them from. But what if you want to use different fonts and a scheme that's not available to just copy?

This is Windows Terminal with the awesome Remedy Theme from VSCode, which isn't readily available for Windows Terminal. The font is Fira Code which contains ligature support, converting multi-character representations to glyphs. This is how the prompt displays icons for Git, using powerline-go setup for bash.

This page is a walkthrough of how to set this configuration up, port themes from other terminals along with finding standard schemes for download. There's also a brief introduction on Powerline enabled fonts and where to download them.

Pre-reqs

Download Windows Terminal
Download Fira Code Font - note Light isn't working with ligatures
Download latest Remedy iTerm Colors file and place into convert_color folder in this repo
Download Visual Studio Code

Windows terminal settings and using a readily available scheme from GitHub

This is a themed command prompt profile, it's a good place to start as it uses a scheme readily available to copy from GitHub called Firewatch. If you click on the down arrow at the top of your windows terminal, your Windows Terminal menu opens. At the bottom of the menu is Settings:

Choose Settings and the settings.json file will open for editing in VSCode. There are some great msdocs on how to edit your settings. Here you are going to start by adding a new scheme. Schemes are added into the schemes section of the settings.json file, which is near the bottom of the page:

Copy the Firewatch scheme, including the curly braces and paste it into the settings.json between the square brackets, it should now look like this:

If you don't like the look of that scheme, go up a level in the GitHub repo, there are hundreds more, with screenshots here!

The scheme is named "Firewatch", this name is used to reference the scheme. The reference can be used in the default profile, which will apply it to all profiles, or a single profile. A profile is each terminal type that has been set up in Windows Terminal, such as Command Prompt, Powershell or WSL.

In this example, the firewatch scheme is only to be applied to the command prompt. Scroll up in the settings.json file until you see // Make changes here to the cmd.exe profile.:

To reference the firewatch scheme add

"colorScheme": "Firewatch"

into the cmd.exe profile, make sure you add a comma after

"hidden": false,

:

Save the file, if you have the Command Prompt open in your windows terminal it will change automatically. Note that settings at the profile level override those at the default level.

Setting up your own theme and converting one from iTerm2

Creating your own Scheme

The color schemes section of msdocs gives the format required to create your own scheme. You can paste a second section into the schemes array (the square brackets) and give it a name other than one that already exists. For example, this could be "powershellScheme", add the named reference to another profile using

"colorScheme": "powershellScheme"

. Now as you edit the hex representation of the colours for powershellScheme and save the file, the changes will be displayed immediately in Windows Terminal.

Conversion from iTerm2

Another way is to take a theme from a different terminal. The schemes structure uses a JSON variant of the iTerm2 colour scheme format. This format can be ported for use by many terminals as listed on the iTerm2-Color-Schemes GitHub page. The scheme displayed on the first screenshot in this page is from the Remedy VSCode theme. The Remedy GitHub repo contains the .itermcolors file which enables the same theme in iTerm2. You can also export schemes directly from iTerm2 to .itermcolor files.

The .itermcolors file looks complicated, but it can be ported for use in Windows Terminal using an itermcolors to hex convertor. There are many scripts available to do this on various sites, for this walkthrough a PowerShell converter example and a go convertor will be shown.

Conversion with PowerShell

For PowerShell, download the ConvertFrom-ItermColoursToHex.psm1 and save as a file of the same name. To load in the module, open a PowerShell terminal and from inside the same folder you downloaded the psm1 file:

Import-Module ./ConvertFrom-ItermColoursToHex.psm1

With the module imported, it can be used to convert a .itermcolors file. You'll need to have an .itemcolors file to convert in the directory you run the following command from. Step 3 in the prereqs has the GitHub repo for Remedy Dark, which has been renamed to "remedy-dark.itermcolors"

[xml](Get-Content ./remedy-dark.itermcolors) | ConvertFrom-ItermColoursToHex

The names listed correspond to the equivalents in the Windows Terminal scheme. Open the settings file within Windows Terminal once more. Copy a scheme within the settings.json file and rename the scheme as "Remedy-dark". Now match up the names and overwrite the hex values as shown, note they are not in the correct order:

Assign the name reference to a profile, in this case, I'd like the scheme to be my default colour scheme. Scroll to the top of the page and add

"colorScheme": "remedyDark"

into the defaults section:

Save the file, and all of the profiles will have the same theme, unless you have a colour scheme defined at the profile level.

Conversion with Go

To complete the same steps using go on a Ubuntu WSL distro. Install go if you don't already have it:

sudo apt update
sudo apt install golang-go
go version

Download the palette.go file and save as a file of the same name. With go setup, you can run the script. Note you'll need to have an .itemcolors file to convert in the directory along with your palette.go script. Step 3 in the prereqs has the GitHub repo for Remedy Dark itermcolors file, which has been renamed to "remedy-dark.itermcolors". In the same Ubuntu WSL distro that you installed go on, cd to the directory with your script and color file in and run:

go run palette.go -colors remedy-dark.itermcolors

The output this time is slightly different, the hex values are in the correct order, but the names do not tally. "Ansi 0 Color" is "black", "Ansi 1 Color" is "red" and so on. Copy a scheme within the settings.json file and rename the scheme as "Remedy-dark". Now match up the top 16 rows and overwrite the hex values as shown, then copy "Background Color" into "Background" and "Foreground Color" into Foreground.

Save the file, and all of the profiles will have the same theme, unless you have a colour scheme defined at the profile level.

Changing your font

Cascadia Code became the default font for all profiles automatically generated by Windows Terminal in release 0.11. Cascadia Code is an awesome font for developers, but I'm a fan of Fira Code and JetBrains Mono. If you downloaded FiraCode and installed the fonts from the pre-reqs steps you are ready to go.

Open your Windows Terminal settings once more and scroll to the defaults section for profiles, this will set the same font for all of your profiles. Add the following into defaults:

    "fontFace": "Fira Code",
    "fontSize": 10,

Save the file and the font settings will be applied.

As described in the introduction, Fira Code contains Powerline Glyphs, which means it will automatically show the special characters in my prompt (See the "What about a funky prompt!" section below). If you are sticking with Cascadia Code, you'll need to download the Cascadia Code PL fonts which are not shipped with Windows Terminal. The process to install and use the font is the same as above, except the fontFace is

"fontFace": "Cascadia Code PL"

You don't have to stick with Cascadia Code or Fira Code either, the Powerline Fonts GitHub repo contains many fonts that have been patched for Powerline.

Note - if your fonts don't automatically load after you've shut WIndows Terminal down and re-opened it, I found that installing the Font for all fixed this. I haven't looked into why.

If you are running Windows Terminal 1.1 preview or above and have a font that support it, you can now also specify a weight:

    "fontFace": "Fira Code",
    "fontSize": 10,
    "fontWeight": "light",

What about a funky prompt!

There are a few ways to do this, however, msdocs has a good tutorial which is how the prompt in these screenshots is setup.

SSH With Windows Terminal profile

Thomas Maurer has a great tutorial on how to set up profiles to SSH you straight in, it focuses on Azure VM's but the

commandline

can be altered to any address.

Create an Azure Pipeline for a .NET Core Webapp and configure for Continuous Integration (CI)

Nicole Stevens — Mon, 06 Apr 2020 15:27:06 +0000

Introduction
Prerequisites
Step 1 - Setup the ASP.NET Core Webapp project
Step 2 - Understanding the build and publish process
Step 3 - Create a build pipeline
Step 4 - Manually running a pipeline
Step 5 - Configuring for Continuous Integration
Conclusion

Create an Azure Pipeline for a .NET Core Webapp and configure for Continuous Integration (CI)

Introduction

In parts one and two of this guide, you have been working with editing the readme.md and pushing markdown changes to your Azure DevOps repo. To create a build pipeline in Azure DevOps you are going to need to work with some code.

In this part of the guide, you will install .Net Core and configure a .Net Core webapp project so that only the parts of the project that require to be under source control are stored in your Azure DevOps Repo. You will examine how the build process you use on your machine needs to be mirrored in an Azure DevOps Pipeline for a successful build. There is a key takeaway from this exercise, no matter the language used, the process to build locally needs to be mapped to the Azure Pipeline.

Once your build process has been mirrored you will automate the process which runs the build. These steps are the start of a journey towards Continuous integration.

Prerequisites

Before working through this guide you will need the following:

An Azure Subscription, you can create a free account.
An Azure DevOps Organisation, the basic plan starts with the first five users for free.
A local installation of Git, following the install guide for your OS. If you are using Windows, ensure the box is checked to Enable Git Credential Manager.

If you installed VSCode before Git, you will also be presented with this option:

This allows you to launch VSCode as the default code editor or difference tool, straight from git on the command line. Please leave as VSCode for this guide, you can reinstall later to pick a different IDE.
An installation of .NET Core, choose to Download .NET Core SDK for your OS and install. Once the installation is complete open a new command window and check .NET Core was installed properly by entering the command dotnet

If you receive the output about from dotnet help, the installation was successful. If you receive the following error:

Make sure you open a new command window and try the command once more.

Step 1 — Setup the ASP.NET Core Webapp project

As part of the pre-requisites, you installed .Net Core SDK ready to build a .Net Core project. To help understand how the Azure DevOps build pipeline is built, you'll look at some of the functionality of the .Net Core CLI. Once you've explored some of the key commands for the .Net Core CLI, you will create a new .Net Core Webapp project and configure the project for pushing to an Azure DevOps Repo.

.Net Core is cross-compatible across operating systems, this means you can run it on Windows, MacOS or Linux. When you installed .Net Core, the .Net Core CLI was automatically installed by the install process. This gives you access to the commands required to develop, build, run and publish .Net Core applications from the command line. You can fire up a command prompt, terminal on Linux or a Powershell/command terminal in Windows and use the same dotnet commands. The .Net Core CLI can also be called by graphical IDE's such as Visual Studio or Visual Studio Code, opening up access to the same commands from a user interface.

Open up your command line of choice and execute the command from the pre-requisites dotnet

Previously you used this command to check that the .Net Core SDK had installed correctly. The dotnet is the driver command, it will always be the first word when working with the .Net Core CLI on the command line. The driver command will either execute a command or run a .Net Core app. When executed on its own as shown above, the dotnet driver command gives instructions on how to get more help. Options can be added to the command, for example, the dotnet driver command can take --version:

Taking the option of --help from the driver command instructions listed above you can see the commands that can be executed with the dotnet driver. Enter dotnet --help into your command line to explore this further:

For a full list of commands and their usage visit the Microsoft Docs dotnet command reference.

Scanning up through the SDK commands you can see new is listed, with the description stating this is the command to create a new .Net project. Each of these commands can take the --help option to view help on their usage. Use dotnet new --help to view the help on the new command:

The output here is split into three sections. The screenshot above shows the first section. These are the options. You can filter the template names using --list or check for locally installed template updates with --update-check. The option --language allows you to pick between C#, F# or VB where the template supports it, with C# being the default. To examine what templates are available, here is the middle section of the help output, the list of available templates:

The command dotnet new uses the templates listed to create .Net Core projects based on the specified template. The template creates a project which will contain all of the files required to start building the application. Looking at the output above, the first column is the full template name, which gives the best description of what the template is for. The second column, Short Name, is the template name used when calling dotnet new.
For example, looking at the top line of the output, executing dotnet new console, will create a project containing all of the files required to start building a console application.
The third column displays whether F# and VB are available for the selected template. Taking the top line of the output once more dotnet new console --language F# will create a .Net Core project that can be used to build a console application in F#. For this guide you will be building a Web Application in Azure DevOps, therefore, webapp is the template name you will use when executing dotnet new.

The final section of the dotnet new output lists examples of how to use the command. Above are examples creating a model view controller app mvc and a nuget config file nugetconfig.

You are now ready to create the project for the webapp. Change directory on your command line to the dotnetcoredemo git repo you linked to an Azure DevOps Repo in part one of this guide. If you have not followed part one, run through Step 1 - Setup a Repo in Azure DevOps to create the required Azure DevOps Project and Repo.
List the contents of the repo using dir /a /b on windows or ls -al on a Mac or Linux:

The local repository is pretty much empty, it has the readme you edited in the previous part of this guide and the .gitignore created by Azure DevOps. Create the .Net Core Webapp project files in this directory using dotnet new webapp

The dotnet new webapp command recreates the template structure in the directory it is run from, and then restores required packages to the template structure using dotnet restore. The project is now ready to use, you can explore the project in Visual Studio Code by executing code . from within the dotnetcoredemo folder:

In the explorer view of VS Code, you can see the outline of the template combined with the .gitignore and README.md from the local git repo. Looking to the top you'll see the obj folder is greyed out and the properties folder is a slightly darker colour of grey. This is due to the .gitignore you added in part one of the guide Step 1 - Setup a Repo in Azure DevOps. Open the .gitignore file in VS Code and scroll down to the Build Results section:

The folder obj has been flagged to be ignored, this is shown in the screenshot by being light grey. The obj folder and none of the files it contains will be pushed to the repo. If you scroll throughout the file, you'll see all the file types and folder names that should not have their files tracked in the git repository. Scroll to the .Net Core section, **/Properties/launchSettings.json. The instruction tells git to ignore launchSettings.json when it's found under the Properties folder, but not to ignore other files in that folder. The instruction not to include every file in the Properties folder is why this folder is a darker grey than obj.
The .gitignore keeps your repository lean, only code changes are tracked. This also stops binary objects such as compiled code packages, which git is not designed to version, from being stored in your repository.

If you did not add the .gitignore for Visual Studio previously, you can create this manually. Switch back to your command line and run git status:

This local repo has the .gitignore set for a .Net Core webapp so the Obj and Properties directories are not showing up in the changes above. Deleting the file and running git status once more:

The output from git status above in "Untracked files" is what you will see if your .gitignore was not added. On the command line create a new and empty .gitignore file using nul > .gitignore on windows or touch .gitignore on MacOs or Linux. Open the folder with code . and open the empty .gitignore file. Open a browser and navigate to VisualStudio.gitignore

The .gitignore for Visual Studio is displayed. This .gitignore file is from the collection of .gitignore templates held at github. Click Raw to open the raw content of the .gitignore file. Select all, copy and paste the content into the empty .gitignore file open in VS Code. Save the .gitignore file and return to the command line. Re-issue git status:

The status of the updated .gitignore file is listed along with the untracked files. Note here, if you hadn't set up your .gitignore previously, the .gitignore file will be listed under "Untracked files". Notice that the Properties folder is still present showing there is a slight difference between the .gitignore provided by Azure DevOps and the one from github. For this guide leave the settings as is, however, it highlights how a .gitignore file needs to be tailored for your use case.

You have created a .Net Core Webapp project from a template and set the local git repo to only push the changes that need to be tracked in version control. You are now ready to push your Webapp to the Azure DevOps repo. This process is identical to that performed when editing the README.md:

Your new webapp code has been pushed to your Azure DevOps Repo. Open the Repo in a browser to check the template code:

Step 2 - Understanding the build and publish process

With your webapp code pushed up to the Azure Repo, you are now ready to create your build pipeline. The process of building the Webapp in Azure DevOps mirrors the process that you would type at the command line with dotnet or execute in an IDE such as Visual Studio. If you have not built an app in .Net Core before, you can walk through the steps below to explore the process before you switch to Azure DevOps.

Switch back to the command line and cd into the directory that your code resides in. The command to build an app in .Net Core is dotnet build:

Looking through the output above the first part of the build runs a restore (red box). The dotnet build command runs dotnet restore before the build process starts. The dotnet restore command reads the project file and restores package dependencies using NuGet. Nuget is the package manager for .Net. A package manager gives developers the ability to consume packages created by Microsoft or other authors for use in their code. A developer can also create packages for their teams and others to consume from NuGet. This is a common design pattern, reusable code.

The project file name is listed next to the restore output dotnetcoredemo.csproj. Switch back to VS Code and open dotnetcoredemo.csproj.

This is a new empty project and you have not added any dependencies. If dependencies had been added to the project they would be listed where the empty space is marked on the screenshot above, which would look like this.

Looking back at VS Code, you can also see a bin directory has been created in your local repo. It is greyed out and marked to be ignored by the .gitignore. The bin directory is ignored as it contains binaries that should not be pushed to your repo. The bin directory was created by the second part of the dotnet build command. The output of this command was shown in the previous screenshot in the yellow box. dotnet build takes the dependencies in the project file and builds the dependencies and the code into binaries. You can see the compiled code output as .dll files to the bin folder listed within the yellow box of the dotnet build output above.

If you look through the path to the .dll files displayed in the build portion of dotnet build it is \bin\Debug\netcoreapp3.1\, it contains the word Debug. When you build a .Net Core application it's default configuration is to create a debug build. For a production build and for this guide, you want to use a release configuration, to do this use the --configuration option dotnet build --configuration Release

Switching back to VS Code, you will now have Debug and Release builds in the bin directory:

If you open these folders you'll see the files that you need to run the application. However, this is not the officially supported way to distribute the application. To prepare the application for deployment you need to run dotnet publish dotnet publish --configuration Release where the configuration option is the type of build you want to publish:

The publish directory now contains all the files required to deploy your application.

If you step back through the processes above you will see there are three steps:

dotnet restore - restore dependencies and code
dotnet build - build your code
dotnet publish - publish for deployment

If you recall the very start of this step of the guide, you need to mirror the process from the command line to Azure DevOps. Therefore, the three steps above are those required to build and publish your webapp in Azure DevOps. Switch to Azure DevOps so you can explore this process.

Step 3 - Create a build pipeline

Switching back to Azure DevOps you should still be in the Azure Repo for the dotnetcoredemo project. Choose Pipelines in the left-hand menu and then Pipelines once more:

An Azure Pipeline is used to automate building a project. You can build your code, test your code, analyze the quality of your code and feedback the results all within one pipeline. Thus providing some of the fast feedback loops that are a corner-stone of DevOps.

To start creating a Pipeline, click Create Pipeline:

You now have the choice to start creating a Pipeline in YAML, by selecting where your code is stored. Building a pipeline in YAML is best practice when using Azure DevOps. It allows you to version control your pipeline in the same code repository as your code. However, when you start to configure Pipelines, it is best to use the UI. This allows you to explore the basics of a pipeline by adding items to the pipeline manually. For manual work with the pipeline, you will need to use the classic editor. Click on the classic editor:

The classic editor starts with the choice of where to select your repository from. The repository selector defaults to Azure DevOps, with the current project and Azure Repo loaded if you have one. You can also select which branch of your Azure Repo to build from. Your Git workflow set up in part 2 of this guide expects builds to be from the master branch. The settings should be all defaulted in for you, so click continue:

The classic editor is pre-loaded with templates to carry out different types of build. You are building a .Net Core Webapp, so scroll down through the templates and click on ASP.NET Core and then click Apply:

The template for a .Net Core pipeline is loaded. Looking at the tasks that have been created for you, you'll see they almost mirror the steps we looked at for publishing a .Net Core application locally. A task in Azure DevOps are steps required to automate a process, in this case, a build, within a pipeline.

There is an extra task - Test, this will run tests as defined in your code repository. Testing code using unit tests at the build stage is another essential part of DevOps. However, for this guide there are no test tasks defined in your repository, therefore we can delete this task. Click on Test, then in the top right click Remove:

The test task is removed and the pipeline now mirrors the steps for publishing a .Net Core application you explored in Step 2 of this part of the guide. Click on Pipeline at the top:

These are the settings for the pipeline. You can configure the following for this configuration:

Name - you can alter the pipeline name to fit the pipeline you are creating. Change this to dotnetcore-CI.
Agent Pool - an agent is a Virtual Machine which has software already installed ready to run the tasks in your pipeline. An Agent Pool is a group of agents of identical specification and configuration. An agent pool can be utilized across one or more projects in an Azure DevOps Organisation. Agent pools are hosted by Microsoft or Self Hosted (Private). The default is a Microsoft hosted pool named Azure Pipelines, this is what you will use for the build in this guide. You can see it is Microsoft hosted by selecting the dropdown:
Agent Specification - you chose the default of a Microsoft hosted agent pool, which enables the agent specification drop-down. The agent specification dropdown gives you the option of selecting a specific operating system to suit the requirement of your build. Each specification can have slightly different software pre-installed to run the build tasks. You can choose from MacOs, Windows, Linux, select the dropdown to explore the options. .Net Core is cross-platform and can be built on Linux so leave the specification as ubuntu-16.04:

The pipeline settings are correctly configured, now click on Agent Job 1. A job is a series of tasks that are run sequentially. A job runs on an Agent. In this guide we are creating a build, so edit the name of the job to Build. Leave the rest of the job configuration at the defaults. Click on Restore:

In the right-hand pane is the heading .Net Core, with an information icon next to it. Click the information icon:

Here you see the information about the task. This is the .Net Core CLI task, it has the same functionality as running dotnet on your local command line. It is the dotnet driver. Exploring the options for this task:

Task version - each task is versioned to stop issues with backwards compatibility when new functionality is released for a task. Leave this as 2.*.
Display name - this is the name shown in the job on the left-hand side of the pane, leave as Restore.
Command - this is the command sent to the dotnet driver, in this case it is restore. If you click the dropdown for the command you can see the same commands you viewed when running dotnet --help on the command line:

Choosing Restore gives the same functionality as running dotnet restore. Leave this as restore.
Path to project(s) - if you recall from Step 2 of this guide, dotnet restore restores the dependencies from the .csproj file. This path defines where to find the .csproj file within the project.

The defaults are all acceptable here, click Build:

The first four configuration options shown are identical to that of the Restore task above. However, the command is using build. If you recall the build section of Step 2 of this part of the guide, you have the option to build a Debug or Release optimised build. To do this you use the --configuration parameter. You can see this at the bottom of the screen-shot above defined as the Argument --configuration $(BuildConfiguration). Items defined with $() are Variables. Variables can be created at the Pipeline level and used throughout the Pipeline. To see this click on Variables towards the top left of the two panes:

The BuildConfiguration variable has been set up by the .Net Core template to Release. This pipeline will build a release optimised application. Click on Tasks and click on Publish:

Once again the first four configuration options have the same function, with this task using the publish command. This task is set up to publish the .Net Core web project and zip up the output. If you look at the Arguments for the publish command, there is a new argument, --output. This is instructing the publish to place the items being published into a specific directory. The directory --output $(build.artifactstagingdirectory) looks like a pipeline variable. However, it is a predefined variable, this has been automatically set by Azure DevOps. This defines a path on the agent where the published output will be copied to.

The defaults here are as required, click Publish Artifact:

At the point dotnet publish finishes on the Agent, the application is still on the agent and needs to be copied out and made available for use. At the top left of the right-hand side pane, click the information icon next to Publish build artifacts.

The publish build artifacts task enables you to copy your published build out to Azure DevOps or a file share. The item published at the end of the build is known as an artifact, it is a collection of source code and dependencies that make up a deployable component of an application. In the case of this guide, there is only one component so the artifact is the application.

Looking through the task options, Task version and Display name have the same purpose as previously described tasks.

Path to publish - this is the path on the agent to get the artifact from. You can see the template has been set up to use the same variable $(build.artifactstagingdirectory) that was used for the dotnet publish task. This ensures that the output from the dotnet publish task is published as the artifact.
Artifact name - the name of the artifact you wish to create.
Artifact publish location - choose between publishing the artifact within Azure DevOps for other pipelines to use or on a file share:

You can leave all of these at the default options. Your pipeline is now ready to run!

Step 4 - Manually running a pipeline

You have set up the job and it's tasks for your pipeline, but so far it has not been saved. Click Save and queue at the top of the classic pipeline editor page. Now click Save and queue in the drop down, this saves the pipeline and queues it to run:

This brings up the Run pipeline page, which enables you to manually run your pipeline.

The Save comment is optional, however, you can add a meaningful comment to your run. The rest of the options are taken from the pipeline setup. You will notice that the top three drop-down boxes are taken from the Pipeline settings you explored near the top of this step in the guide. Click Save and Run to run your pipeline:

The run page loads and the job is queued. The pipeline is now trying to get a build agent from the hosted pool, this is why it is queued. Once the build agent is assigned the Job starts to run:

Until it is either listed as a Successful or Failed build:

At any point you can click on the name of the job to look at the status of each task in the build. Click on the job name to explore the output that is displayed by the running tasks:

The top of the list of tasks is the job summary, here you can see the pipeline settings, how long the job ran, and that an artifact was produced. The artifact message is a link, click on it to view the artifact that was published:

You can expand the drop folder and see the zip file that was published. If you hover the mouse to the right of either the zip file or drop folder you can download the output. Download and open the zip file, it has the same structure as your /Release/Publish folder had in Step 2 of this part of the guide:

The build status had already marked the build as successful, however, you have just checked this by looking at the published artifact. Now you can explore some of the output from the steps in the build. This process can also be used to debug the build in the case of failure. If any of the steps had failed, the status circle to the left of the task name would have contained a red cross. Click the back arrow at the top left by Artifacts, scroll down and click the job name and then click "Checkout dot...":

The first task the agent must perform is to fetch the repo and checkout the master branch. You didn't have to perform this task locally as you already had your code in your local repo. The commands in blue in the output windows are the git commands being issued. The build agent is performing the same sequence of commands to fetch the code and check it out, they just look slightly different:

git init "home/vsts/work/... - the path to initialise the git repo in is being passed to init, rather than calling init from inside the folder.
git remote add origin - this is identical to the command you would call on your local command line.
git -c http.extraheader="AUTHORIZATION: bearer ***" fetch --force --tags ..... origin - this is a git fetch. -c http.extraheader="AUTHORIZATION: bearer ***" is overriding part of the git config with a bearer token to add into the header. The stars show the bearer token has been hidden as it is a secret. This token gives the agent access to the Repo, the agent does not have to login. The fetch is fetching the origin remote, you can see origin at the end of the command.
git checkout --progress --force adfd5b...2825d - this is a git checkout, it is switching to the SHA checksum of the last commit to master when the build job started:

You can verify the SHA is correct by switching to the commit history in the Azure Repo. The initial 8 characters of the SHA checksum are displayed, however, if you hover to the right of history line, you can copy the SHA checksum from the "More" menu to see it is identical. Note, you must compare the ones in your repo/checkout output, as they will be different from the ones shown here.

The command git checkout origin master will switch to master as it looks when the git checkout command is run. If there was a time delay in acquiring a build agent, it is possible further pushes to master have happened in that time. This is why the SHA checksum is used, it guarantees that the code being built is how it looked when the pipeline run started.

Now click on the Build task:

You can see the dotnet build command in blue, it is being passed the full paths to the .csproj file, along with some options for logging. It is, however, performing an identical process to that carried out locally on your machine. You can verify this by comparing the dotnet build output from your command line, to that displayed in the task output. You should see the only difference is the output paths.

Click on the other steps to familiarise yourself with how task output looks between different types of tasks.

You've now finished exploring a manual run of an Azure Pipeline. However, you do not want to be triggering a build manually after every pull request! Automating the builds will add further value, this is part of the process for Continuous Integration.

Step 5 - Configuring for Continuous Integration (CI)

Continuous integration (CI) is the process of automatically building and testing code when it is committed to version control. This can be on every push, or a pull request completion. The process can also be automated for changes from one or more branches.

Azure DevOps supports CI through triggers on the pipeline. A trigger can be:

CI trigger - builds are triggered on every push to a branch or branches.
PR trigger - builds are triggered on a push to a pull request on specified branches.
Scheduled trigger - builds are scheduled for specific times of the day/week. This can be useful for a testing team new to DevOps who would like to start with a nightly build.
Pipeline trigger - this is for large products with dependant components. If a change is detected in a dependant component, the trigger will fire off a new build.

To set this up in Azure DevOps, you will need to edit your pipeline. Enter the Pipelines menu:

Click your pipeline name:

Here you can view the runs for your pipelines. Click Edit in the top right:

You are taken back into the pipeline classic editor you worked with to set up the pipeline. Towards the top, click the triggers tab:

Here are the options as discussed in the CI introduction above. It is not possible to use Build completion, also known as a Pipeline trigger, as there is only one pipeline in this project.

You are setting up a Continuous Integration trigger for this pipeline. To do this, click the project name under Continuous Integration and tick Enable continuous integration:

There are some options you can set on continuous integration:

Batch changes while a build is in progress - if you work on a large team where there are frequent pushes and/or PR completion pushes, you may end up queuing multiple builds while a build is still in progress. This checkbox will stop each of these pushes being queued as a separate pipeline run. It will queue one run of all the changes once the current build is complete.
Branch filters - include or exclude branches for the trigger.
Path filters - this is often used to exclude changes from a build, for example, "always trigger on master except for when there are changes to the reports folder". In which case you would exclude the path to the reports folder in the Path filter and include master in the Branch filter.

For this guide, we are going to trigger on every push to master, so accept the defaults by clicking Save & Queue and Save:

You can optionally add a comment for your pipeline change, then click save:

This saves the changes to your pipeline but does not manually kick off a build. To trigger this you will need to push a change to your Azure Repo.

Switch back to VS Code, you are going to make a small change to the index page of the webapp to trigger the build. Open Pages/index.cshtml:

Edit the header line to something appropriate:

Save the index.cshtml page and switch to your command line to push the change to your repo:

Quickly switch back to Azure DevOps, and click on Pipelines:

The pipeline has been queued. Click on the pipeline name to view the pipeline runs:

Your first run states it was Manually triggered, the latest run says it was triggered by an individual CI. Your push to master has triggered the build.

Congratulations, you have automated your build process!

Conclusion

In this article, you have explored how the .Net Core CLI works. You used the CLI commands to create a .Net Core Webapp project which you pushed to an Azure DevOps Repo. You examined the .gitignore file and how it is important to keep your code repository lean and to not check in binaries to your repo.

You configured an Azure DevOps build pipeline, mirroring the build process from your local machine into the pipeline. You manually triggered your pipeline and watched the steps execute to view where you would debug the process if there was an error. Once the build was successful, you verified the published output by downloading the artifact and checking the contents of the compressed file.

Finally, you automated the process by enabling a Continuous Integration trigger on the master branch of your Azure DevOps Repo. You tested the automation by pushing a change to master and verified that the build was triggered by the push.

If you recall the definition of Continuous integration (CI): "It is the process of automatically building and testing code when it is committed to version control." If you also look back to the beginning of this part of the guide, Automated testing is displayed as a driver to the Continuous integration construct. To add further value to your newly automated build process, you must be automatically testing every build. The next part of this guide will add a test and a test task to your pipeline.

Working with the Feature Branch Workflow and Pull Requests

Nicole Stevens — Tue, 17 Mar 2020 11:22:15 +0000

Working with the Feature Branch Workflow and Pull Requests

Stepping back to part 1 of this guide you've been a lone developer, cloning your repository, making changes locally and pushing them back up to your remote. What happens when other developers need to make changes, at the same time as you, and in the same repository? How do you ensure the changes follow your coding standards and are of sufficient quality? This is where implementing a git workflow is crucial, to ensure changes are reviewed and merged back into the main code line. A common Git workflow for a team has the following steps:

Create a branch for the changes you are going to make. A branch is an isolated version of the code that you can work on offline without impacting other developers on your team. A branch would typically be for a new feature or a defect fix.
Commit changes to your branch locally. You can keep track of your commit history locally while you work.
Push your changes to the remote repository, in the case of this guide, Azure DevOps.
Create a Pull request so that one or more people on your team can review your changes.
Review the pull request. One or more team members perform a quality check on the code. The criteria for checks of these changes will often be laid out in a code review checklist which are likely to include the coding standards of your team or organisation.
Complete the pull request. The team members who are required to review your changes agree that the criteria for changes have been met. The pull request is completed and the changes are merged into the main code line - the master branch.
Delete the branch. Once the code changes and history are merged, it's good housekeeping to delete the branch.

This workflow is often called the Feature Branch Workflow or Topic Branch Workflow.

The code in your master branch should pass tests, build cleanly, and always be current. Your master branch needs these qualities so that feature branches created by your team start from a known good version of code. The workflow above enables this.

Prerequisites

Before working through this guide you will need the following:

An Azure Subscription, you can create a free account.
An Azure DevOps Organisation, the basic plan starts with the first five users for free.
A local installation of Visual Studio Code (VSCode)
A local installation of Git, following the install guide for your OS. If you are using Windows, ensure the box is checked to Enable Git Credential Manager.

If you installed VSCode before Git, you will also be presented with this option:

This allows you to launch VSCode as the default code editor or difference tool, straight from git on the command line. Please leave as VSCode for this guide, you can reinstall later to pick a different IDE.
An Azure DevOps Project. Check out part 1 of this blog series, you'll be using the Azure DevOps Project and Repo created in Step 5.

Step 1 — Configuring branch policies in Azure Repos

You can use branch policies in Azure DevOps to set rules that must be followed when working with branches:

Require code reviewers
Limit who can work on branches
Guarantee changes build before merging to master

These are all examples for branch policies. You are going to explore Require code reviewers.

Open Azure DevOps and open the dotnetcoredemo project you created in Part 1 of this series. Hover over the Repos menu item on the left, when the menu pops out click Branches.

The default on this screen is to show all of the branches that you have created as the filter "Mine" has been automatically selected at the top. You haven't created a branch yet, so only the master branch will be shown, all users have the master branch under "Mine". Move your mouse to the right of the star (which signifies this is the default branch) and a three dot menu will be displayed:

Click on the ... context menu and choose Branch policies at the bottom of the menu.

This opens up the Branch policies, where you can choose from the following options:

The more commonly used options for branch policies are:

Require a minimum number of reviewers - when a pull request is issued, you can set the number of reviewers that must approve the changes before the changes are merged back into the branch. You can also set the policy such that a reviewer cannot be the person who checked the code in. This will ensure that more than one set of eyes passes over your code, increasing quality and spotting mistakes before the code hits QA.
Check for linked work items - this links a pull request to one or more work items. A work item is an Azure Boards unit of work, for example, a bug, feature or task. When this option is turned on, the comments against the commits in the pull request are checked for work item numbers. If none are found, the pull request can either be blocked or a warning message displayed.
Check for comment resolution - A comment can be placed on a pull request. This will often happen if a reviewer requires clarity on code within the pull request, or if standards are not met. Checking this option requires all comments to be resolved, blocking the pull request completion. This can also be set to optional, displaying a warning if comments are still to be resolved, but the pull request will complete.

For this example, tick Require a minimum number of reviewers

Set the reviewers to 2, and tick Requestors can approve their own changes. In practice, it's unlikely this box would be ticked, a team would not want the person who wrote the code to review it. You are setting it in this guide to lessen the complexity of the example. Once completed, click Save changes at the top.

The master branch now requires two members of the team to approve a pull request before the changes can be merged back to master. However, at the moment you only have one team with one team member in this project. You can check this by hitting the project settings cog on the bottom left, then Teams on the Project settings menu:

There is only one team on the list, the default project team. This was created when the project was created. The number under the Members column shows how many team members are in this team.

In the next step, you will add another team member by adding users into Azure AD and connecting your Azure AD to your Azure DevOps organisation.

Step 2 — Integrate Azure DevOps with Azure AD

In this Step you, are going to hook up your Azure DevOps organisation to Azure Active Directory (Azure AD). Azure AD is the identity and access management service for Microsoft cloud services, including Azure and Office 365. Azure AD enables an organisation to grant it's employees access to resources within Azure. If you are familiar with an on-premises Active Directory, Azure AD is an implementation of some of the on-premises Active Directory functionality, including user management.

You will add a new user to Azure AD, then add the same user to Azure DevOps, granting that user the permissions required to approve a pull request.

First, login to the Azure Portal as the user you setup in the pre-requisites of Part 1. In the search bar at the top of the Portal, start to type Azure Active Directory and click on the resource when the list of matching resources is displayed:

This opens up the default directory for the associated Azure Tenant. The directory houses all of the users for the Tenant. Click Users under the Manage menu item:

If this Azure account was created specifically for following this guide, there will only be one user present in this directory. This is the user that you logged in as when you created the tenant. Hit New User towards the top of the screen:

At the top of the New User page, you'll now have the option to Create a user or Invite a user. Invite gives you the ability to grant access to users who are not housed in your tenant, they do not have to be Azure AD or Microsoft accounts, they just need an email address. For this guide you are going to add a user within your tenant so choose Create user

Scroll down to the Identity section, here you will add the User name, also known as the User Principal Name and Name for the new user

In Azure AD and on-premises Active Directory, the User Principal Name is the unique identifier for the account. Therefore, the entry for User name must be unique for the tenant. If you look to the right of the @ symbol you'll see the default domain name for the tenant, this is setup when you logged in and created this new tenant. Here I have masked the tenant name, if I had logged in as devopsdemo@freemail.com, my default domain name would be devopsdemofreemail.onmicrosoft.com. Therefore, the login when this user is created will be henrykelly@devopsdemofreemail.onmicrosoft.com. You can also view the default domain name on the home page for Azure AD.

The minimum values for creating a user are User name and Name, fill these in and then tick Show password. Take a note of this password, you will need this when you login as the user the first time. Once the minimum values are entered correctly, the Create button will activate at the bottom left. You do not need to change anything else on this page, so click Create.

Your newly created user is listed in the directory. Note that the Source says Azure Active Directory. This means that this user is authenticated to an Azure AD account belonging to this active directory. If you had chosen Invite a user a few steps ago this would say External Azure Active Directory.

You now need to check you can login with this user. Open a different browser to ensure you are not using cached credentials. Login to the Azure Portal with your new user:

You will need to make sure you use your default name and then enter the password noted when you created this user. As this is the first time you have logged in as the new user, you will need to update your password:

Once the password is updated and your new user has logged in without a problem you'll see the welcome screen:

Your user has been added correctly. At the moment the user is only an Azure AD user, the user does not have access to Azure DevOps. Switch back to Azure DevOps using your original user account which setup Azure DevOps in the pre-requisites.

To add in users to Azure DevOps you are going to integrate Azure AD. Click on the Azure DevOps icon in the top right, this will take you to the Azure DevOps organisation home page. Click Organisation settings at the bottom left.

This will show you the settings that affect the entire DevOps organisation. We want to integrate Azure AD so click Azure Active Directory in the menu on the left:

The connect to Azure Ad screen is displayed, click Connect directory

On the next screen, you can choose the Azure Active Directory which will connect the Azure DevOps organisation. The user you are signed in as created the organisation and the Azure tenant, so you can choose "Default Directory" in the dropdown to link the two.

You can connect a directory to an Azure DevOps Organisation that was not created by the same user, the user must be a member of the Azure AD and an admin or owner of the Azure DevOps Organisation, see this Microsoft Docs article for more information.

Note the yellow warning box, this will not display when you choose your Azure Active Directory. This is shown as you have invited user(s) to this Organisation that are not in the Default Directory. You can see which users these are by clicking on the 1 out of 2 member(s) link:

The users listed will be disconnected from the Azure DevOps Organisation, unless they are added as members or guests to the Default Directory chosen for the connection.

Hit Close on the Disconnected user pop up and then Connect on the Azure Active Directory Connection popup. It takes a few moments to connect the Directory and the Organisation, once this is complete you should see the Connect success popup.

Hit Sign out and sign back in again, hit the account you were just signed in as:

Once you've signed back in, the Azure AD Organisation Setting will show the Default Directory as connected:

Now the Azure AD is connected you can assign some access privileges to your users. Staying in the Organisation Settings click Users in the left hand menu bar:

Azure AD is connected but there is only your user listed. Connecting the directory from Azure AD doesn't give all users in that directory access to the DevOps Organisation, it makes them available to add. Hit Add users on the left:

In the Users box, start typing the name of the user you added to your directory, once the user comes up in the search click the name to add into the Users box. Leave Access level as Basic, this grants the user access to most features in an organisation. Check out the about access levels msdoc for more information. Now click the Add to projects dropdown and select the dotnetcoredemo project:

Leaving Send email invites ticked will send an email to all users selected in Add new users inviting them to the Azure DevOps Organisation.

Now that the project has been chosen to grant access to, the Azure DevOps Groups dropdown has been activated and set to Project Contributors by default:

The options here are showing the groups for Default permissions and access:

Project Readers - Can view all items but are unable to make changes.
Project Contributors - Can add, modify and delete items in the project.
Project Administrators - Mostly the same as contributors but are also able to delete key items such as work items and share objects across a project such as dashboards and queries.

Leave the selection as Project Contributors

Don't hit add yet, go back up to the Users box and hit the plus sign to add a new user. Type in an email address that is not in the connected Azure AD:

You can still add users outside of the connected Azure AD, but they will need to click the add url in their invite email for access. Azure DevOps gives a warning of this at the bottom of the Add new users popup:

Remove the non Azure AD user by clicking the cross on the right of the email address. Click Add to add your user.

The user is now listed.

You can now go and check the user's access from within the project itself. Click Azure DevOps in the top left, then the dotnetcore project pane. Click Project Settings at the bottom left to bring the project settings menu up. Now click on Permissions:

The permission groups are listed, in the Members column for Contributors you can see two next to the icon. If you hover over the Members icon for the Contributors group, the avatars for the newly added user and a default permission group are displayed. Click on Contributors:

These are the default permissions settings for a contributor. Scroll down to view all of the permissions you can set. Scroll back up and click Members at the top of the page:

Here you can verify that the user you added is a contributor to the dotnetcoredemo project.

You can now go back to Branch policies and update the policy on the master branch. Using the project menu on the left hand side, hover over Repos and then click Branches:

Go back into Branch policies by clicking the hidden menu of three dots ... at the end of the master branch. Then click Branch policies:

Scroll down to the bottom of Branch policies and click Add automatic reviewers

In the section Include the following reviewers add the user you have just given contributor permissions to, along with yourself. Leave Policy requirement at Required. Note the option For pull requests affecting these folders. In this text box you can set a path or paths within the branch that will trigger the automatic inclusion of specific reviewers. This gives you the ability to set senior engineers as automatic reviewers for key areas of your application. For this guide, leave the setting at the default and click Save.

Setting the two users as Required will mean a pull request cannot be completed on this branch until all of the required reviewers approve the request. The two reviewers are now listed under Add automatic reviewers:

The final part of this Step is to ensure users cannot bypass your newly created policy. On the project menu, click the Project settings cog. Now click Repositories under Repos in the project settings menu. This displays the security settings for the repositories belonging to this project. Click Contributors and you will see that the top option Bypass policies when completing pull requests is Not set. Using the dropdown you'll want to choose deny, so that your policy must be followed.

The changed automatically saved and a green tick is displayed to the right of the box

You are now ready to move on to the next step and work with feature branches and pull requests.

Step 3 — Pushing a local feature branch to Azure Repos

Now you have the branch policies setup, you are ready to create a feature branch on your local machine, push it up to Azure Repos and create a pull request.

Switch back to git and cd to the dotnetcore directory you have on your local machine. Run git status to check your local repo is up to date. The command git branch is used when working with branches. If you run it standalone, git will list all of the branches in your local repo:

You only have one branch currently, that's the master branch as displayed. You can also use git branch to add a new branch. To do this re-issue the git branch command with the branch name you would like to create tagged to the end of it git branch users/nicole/home-blog-feature. Execute git branch once more to list the branches in your local repo:

Note that master is green with a star on it's left and your new branch is white. This denotes that you are working on the master branch. Therefore, any changes you make during editing will be against this branch. You need to execute the git checkout command to switch to the new branch, so that you can work in isolation on your new feature. To do this run git checkout users/nicole/home-blog-feature to switch to your newly created branch. You can then re-issue git branch to check you have switched branches:

Your new branch name is green with the star to the left, denoting it is the branch you have checked out.

You may be wondering why the branch name is users/nicole/name-blog-feature and not just name-blog-feature? This is a common branch naming convention. As you get more familiar with git, you can use conventions such as these to filter a large repo, showing all feature branches or bugfix branches owned by specific users.

Run code . to open VS Code and edit the README.md, paste in the markdown block shown below. This is to simulate making code changes in isolation in your application:

Note the bar at the bottom left of VS Code, due to the integration with Git, VS Code displays which branch you are currently working on:

Save the file and switch back to the command line. From within the dotnetcoredemo folder run git status to view the file changes. Add the changes with git add . and commit with git commit -m "added new blog feature". You are now ready to push the changes to Azure DevOps. To do this you need to tell git to push your new branch to the remote for Azure DevOps, which is origin - git push origin users/nicole/home-blog-feature

If you recall from part 1 of this guide, you can check what you've called your remotes and where they are pointing using git remote -v.

Switch back to Azure DevOps and click Branches under Repos on the project menu. You can now see two branches, the master and your new feature branch. You can see your name under author as you committed the changes and pushed the branch up to the Repo.

Note the folder users/nicole. This shows a small part of the power of a good branch naming convention. Using this convention, you can see all of the branches owned by each of the Repo users by expanding their folder. Hover over the feature branch name, you can now click on the home-blog-feature branch:

This takes you directly to the Files section of Azure Repos and into the selected branch to display the files that are part of this branch.

You are happy that your changes meet the feature requirements and now need to merge your changes back into the master branch. To do this you need to create a pull request by clicking on Create a pull request on the right hand side.

The top two dropdown boxes of the New Pull Request page show that you are requesting to pull the changes in the users/nicole/home-blog-feature branch into the master branch. Your commit message has been automatically added to the Title of the pull request. This is one of the many reasons why you should be thinking about writing good commit messages.

Moving down to Reviewers, here you can add specific members of the dotnetcoredemo project to review your changes. However, you have already setup two users to auto review pull requests to the master branch. So to check this is working leave this blank. Work Items can automatically link to items in Azure Boards if the correct item number(s) are in the commit message(s), or you can add them manually here. If you scroll down below Create, you can see the file changes that are part of this branch. Click Create. The Pull request is created and you are switched to the Pull requests menu item under Repos in the project menu. The pull request you just created is shown:

This is the pull request page, it contains all of the information required to review the pull request. By default, you are taken into the Pull request overview tab. At the top, you can see the pull request has been set to active. Scanning further down below the description, the history of the pull request is displayed. No review of this pull request has started so the history shows that the pull request was created and your new user along with your username were added as required reviewers.

Switching to look at the right hand side, at the top are the Policies that have been set on this branch or path(s) within this branch. The red crosses next to each policy show that you have not met the requirements of the policies listed. If Azure Boards work items had been linked to this pull request, these would be listed on the right hand side under Work Items. The work items are listed as links to allow swift access to related work items for review. Under Reviewers are the required reviewers. If you had selected optional reviewers when the pull request was created, these would also be listed here, grouped under Optional. An email to all reviewers can be sent by clicking envelope icon to the right of Reviewers. By default users are not notified that they are required to review a pull request, however, this can be setup in Notifications for the project.

Hit the Files tab at the top:

Here the files that are different between your branch and master are listed.

You are happy that the pull request satisfies the feature requirement and follows coding convention, so click Approve near the top right to approve it.

A green tick and your user's avatar is placed next to the Approve button to show you have approved it. Click on the Overview to the left of the Files tab:

The overview screen has been updated with the approval. In the left hand column in the history of the pull request, the Approval is shown as the latest item of history. On the right, the Policies have been updated to state that one of the two required reviewers have approved this pull request. Looking further down on the right under Reviewers, there is a tick next to your user's name, you have reviewed and approved the pull request.

You still cannot complete this pull request. The user you added as part of this guide must review and approve the pull request first. Open another browser and sign into as the new user. Note you'll need to include the Organisation on the URL. In this example, my organisation is devopsdemo0755, so my url would be https://dev.azure.com/devopsdemo0755.

Enter the dotnetcoredemo project, then navigate to the pull requests list page using Repos on the left hand side menu, and then Pull requests.

The list displays that there is a required approval assigned to you. Click on the pull request name to enter the pull request overview page. You are going to approve this pull request, but first look at the options a user has after the review. Click on the dropdown arrow to the right of Approve

Approve - agree with the changes as they are.
Approve with suggestions - approves the pull requests, but opens a text box to leave suggestions for the author to improve the code.
Wait for author - you can add comments to the overview screen, this option signals that you wish the author to review your comments before continuing.
Reject - the changes are not acceptable, you must leave a comment to explain why.

Hit Approve in the list, the pull request approval screen is updated once more:

On the left hand history trail, the approval by your new user has been added. Moving to the right at the bottom, you have ticks next to both required Reviewers. Moving to the top right, you have two ticks next to your Policies. Two reviewers have approved and the required reviewers have approved. All of your Policies have now been met, and the Complete button has become enabled top right. Click the Complete button to merge the changes into master:

The Complete pull request popup is displayed. The title of the pull request is brought through to become the complete comment. If there are any associated work items for this pull request, these can be automatically set to completed by ticking Complete associated work items after merging. The user you are now logged in as does not have the permissions to delete the feature branch, so this option is greyed out. Click Complete merge.

The pull request is marked as complete, with the username that completed it and the complete comment is also displayed.

Go back to the other browser which is logged into Azure DevOps as your original user. Click Repos on the project menu, then Branches and select the master branch. This opens the files that are on the master branch. You can see that the README.md has the commit against it that came from the feature branch you merged in. Scrolling down you can see the text in the README.md itself, confirming that the merge was successful.

If you now click the History tab towards the top of the screen, you can see a detailed view of the commits against the master branch and where pull requests were merged in. This is showing a key part of how Git works on merging. Not only are your code changes brought across, but also the history of your changes.

Note, it is possible to condense the history of a branch when merging, this concept is beyond a beginners guide.

You have confirmed that your code changes and commit history have now been safely merged into the master branch. You can now go ahead and delete the feature branch, the next step will take you through deleting a feature branch.

Step 4 — Deleting a feature branch

When using Git it's considered good practice to delete your branches once you're finished using them. Apart from being a good housekeeping exercise, this practice means that all of the branches in your repo are current and actively being worked on.

First, make sure you are in the Azure DevOps browser window which is logged in as your original user. If you are logged in as the new user, you will not be able to delete the branch in Azure DevOps as that user does not have permissions to do so. Navigate back to the branches list using Repos on the main project menu and then Branches. Move your mouse to the right of the branch which has been merged in the previous step. On the hidden menu of ... choose Delete branch

A popup is shown to check you are sure you want to delete the branch. Click Delete, your branch is deleted.

If you recall the Complete pull request screen from the previous step, there was the option to Delete users/nicole/home-blog-feature after merging.

If the user had the permissions, and the tick box had been checked, the branch would have been automatically deleted after the merge. Therefore cutting out the manual delete that you have just performed.

The branch is now deleted in Azure DevOps, but you still have it on your local repo. You can see this by switching back to the command line and executing git branch having cd to your git repo:

The branch users/nicole/home-blog-feature is still present. You need to move off of the branch you want to delete, so switch to master using git checkout master. Check you are on the master branch using git branch. Now issue the delete branch command, this is performed using a -d on git branch with the branch name tagged to the end git branch -d users/nicole/home-blog-feature:

This hasn't deleted the branch locally, the error message is saying that the changes in users/nicole/home-blog-feature have not been merged into the master branch. This is to stop users from deleting branches that have not been merged. So far the merge has only happened on the remote at Azure DevOps following completion of the pull request. Therefore, you need to pull the merged changes down from the remote to the local master branch with git pull:

You have now pulled the changes from the merged to master on the remote on to your local master. Note the section that is Updating d65422c..4202971, if you recall the branch history page you looked at in the last step:

The red boxes are circling commit ids these are unique identifiers for the commits to a repo. If you look at the first commit id in Azure DevOps and compare to the first one in the command line output, you'll see they are identical. Similarly with the last one in both screenshots. This gives you a small look into what is going on under the hood. If you recall from part 1 of this series, a git pull performs a git fetch and then a git merge. In this case git pull fetches all the changes from the point where the local repo and remote repo diverged. This is from commit d65422c. If there were changes to the master branch locally, git pull would try to merge the changes. For this walkthrough there are no changes to merge, so the branch is now at commit 4202971, identical to that of the remote repo.

If you had decided not to push the branch changes to the remote, you can force the deletion of a branch without a merge using -D as described in the command line output.

Try the branch delete command once more git branch -d users/nicole/home-blog-feature:

The branch deletes successfully, you can check this by issuing a git branch and only the master branch exists locally.

Conclusion

In this blog post you have explored feature branches and pull requests with Git and Azure DevOps. You created a local feature branch, this branch enabled you to code in isolation to other developers on your project. You committed your changes locally to your new branch, then pushed this branch to your remote.

Next, you looked at how to integrate Azure AD to Azure DevOps, securing features of Azure DevOps to users in your Azure AD, therefore streamlining user management. You added a new user in Azure AD and assigned this user a Contributor role to your project in Azure DevOps. This enabled you to setup a minimum of two reviewers for a pull request within a branch policy.

You created a pull request, using two required reviewers. You noted how each action in the pull request builds up a history for the pull request that can be viewed. You saw how the branch policies stopped the pull request from being completed until all policy requirements were met. Finally, you deleted you feature branch once your changes and history were safely in the master branch.

This process simulated a small team working on changes and reviewing each others changes ensuring code quality. In the next part of this series you'll work with a sample .Net Core application and push it through a build pipeline.

Getting started with Git and Azure DevOps

Nicole Stevens — Sat, 01 Feb 2020 20:14:26 +0000

Introduction
Prerequisites
Step 1 - Setup a Repo in Azure Devops
Step 2 - Cloning the Azure Repo
Step 3 - Saving changes with commit and push
Step 4 - Updating Code with fetch and pull
Step 5 - Pushing an exitisting repository from the command line
Step 6 - Working with GitHub
Conclusion

Introduction

According to the State of DevOps 2019, best practice use of version control is one of the foundations for improving Software Delivery and Operational (SDO) Performance. In this first part of a three part guide, you'll be working with Git and Azure DevOps to setup a repository which you'll use for source control. Source control, also known as version control, has many benefits, each of these benefits come together to create a feedback loop to a team working on the code under version control. These benefits include:

Collaboration - teams can work concurrently, even on the same sections of code, which are merged together.
Workflows - teams check the quality of each others code, ensuring compliance with coding standards.
Versioning - source code can be tagged so that released versions of code can be referred back to.
History - a full history of the code repository is maintained and linked to a users credentials. If changes are well commented, this can assist in issue resolution.
Automation - actions within a version control system, such as checking in a code change, can be set to trigger other operations, such as compilation and testing.

Once you've worked your way through part one of this guide you'll be able to work with Git, a distributed version control system. You'll setup a code repository as part of a project in Azure DevOps, and a single repository in GitHub, enabling you to work with remote version control in the cloud. You'll be able to initialise both repositories, create copies of them locally and make changes to the files within those repositories locally. Once your changes are complete you'll be able to push those changes back to the Azure DevOps or GitHub repository, using the processes that will enable you to collaborate with a team.

Prerequisites

Before working through this guide you will need the following:

An Azure Subscription, you can create a free account.
An Azure DevOps Organisation, the basic plan starts with the first five users for free.
A GitHub account, sign up to the free plan, this gives you unlimited repositories.
A local installation of Visual Studio Code (VSCode)
A local installation of Git, following the install guide for your OS. If you are using Windows, ensure the box is checked to Enable Git Credential Manager.

If you installed VSCode before Git, you will also be presented with this option:

This allows you to launch VSCode as the default code editor or difference tool, straight from git on the command line. Please leave as VSCode for this guide, you can reinstall later to pick a different IDE.

Step 1 — Setup a Repo in Azure DevOps

In this step you will setup a project within Azure DevOps. An Azure DevOps project can be either public or private, where private projects require a user to be invited before the project can be viewed, cloned or contributed to.

A repository is a place to store version controlled code, enabling one or more developers to collaborate on the code, keeping a history of all changes. This is known as source control. You'll be adding a project which will automatically create a repository, this will enable you to add code and make changes to that code in further steps, simulating how an individual or team works with source control.

First, you need to setup a project, open a browser and navigate to Azure DevOps and login the credentials which you used to create the Azure DevOps organisation in the prerequisites.

The option, Choose Start free with GitHub, is for teams already using source control in GitHub. In this guide you have no version controlled code and want the repositories to sit within Azure DevOps, so choose Start free.

Next enter a Project name, the main steps in this guide use dotnetcoredemo. For Project visibility choose to use a private project, this gives you control over who has access to your project. If you were running an open source project, this would be public. Last pick an appropriate Country/region for your locality.

The project is created and the project page for dotnetcoredemo is opened:

This is an empty project, the menu on the left shows the services, Boards, Repos, Pipelines and Test Plans. For this step you want to be working with a repository so choose Repos.

This is a view of an empty repository, to work with this repository locally, either from the command line or from a client, you will need to generate credentials. On this page you can see a button marked Generate Git Credentials, this will allow you to set a username and simple password to work with the repository. However, it is not recommended, as these credentials have full access to the repository, along with other services and do not expire. The Microsoft Docs article Authentication overview for Azure DevOps recommends to use a Personal Access token, where scope of access and an expiration date can be set.

To create a Personal Access Token, click to open the account settings menu which is top right, then choose Personal access tokens.

You can now see a list of all of your personal access tokens, as this was an empty organisation you will only see the default token created when the organisation was created. Click on New Token:

The form to create the Personal access token is displayed:

Working through the options, Name is the name of your Personal access token, it needs to be unique for your tokens. Organization is your Azure DevOps organisation, at the moment you have one. However, if the logged in user has been granted access to multiple organisations, you can choose "All accessible organizations" from this dropdown. Scopes, here you choose which services this Personal access token can work with. Select Custom defined, as you will want to be using the principal of least-privilege. Each scope maps to a set of permissions for one of the services you saw on the left when you entered Azure Devops for the first time. For this guide you want to work with code, to read and write from the repository, so choose Read, write, & manage and status from the Code section. Scroll up and down through the Scopes to get an idea of how a Personal access token can be tailored, leave all other scopes unchecked. Click Create.

Your Personal access token has been created and can be copied from the successful creation page. Note here the warning from Microsoft, once a Personal access token has been generated and this page closed, it cannot be recovered. Therefore, you must store this securely. If the token contents are lost, it can be regenerated. To regenerate a token, select the token in your Personal access token list and click regenerate:

The success screen is displayed once more and the regenerated token can be copied.

If the token is compromised, it can be revoked, which removes the token from the PAT list.

You now have a Personal access token to access your Repo, so the next step is to start working with the Repo locally. Click Azure DevOps in the top left of the page to take you to your Azure DevOps Organisation home, choose the project that you created earlier, dotnetcoredemo and you are returned to the project page with the resources for the project listed in the menu on the left. Click Repos on this menu to enter the empty repository page. The repository is currently empty, you can choose to initialise it with some common repository files.

Scroll down to the bottom of the Repo page to the Initialize with a README or gitignore section. Ensure Add a README is checked, this will create a readme file at the root of the repository. Typically, a readme gives instructions on how to use the repository, a readme file is a markdown file. You will also want to add a .gitignore file, this file instructs git to ignore directories and file types that are required for your project, but should not be stored under source control in your repository. In this part of the guide we are going to use simple text files, but for an example of a working .gitignore, we will setup the project for .NET, so use the dropdown to select VisualStudio. Click Initialize.

Your Repo is no longer empty, you can see the file list which now contains the readme and .gitignore. The readme is stored at the root of the Repo and is automatically displayed on the page as it is expected to contain instructions on how to use the Repo. Click on the .gitignore file to view an example of a setup for a software development project.

Step 2 - Cloning the Azure Repo

In this step you'll look at cloning a repository to create a local copy on your file system, enabling you

When working on code stored in a distributed system such as Git, which is the backend for an Azure DevOps Repo, you take a full copy of a repository by cloning the repository. This recreates the entire history of the repository locally on the users machine. Click Clone in the top right:

In the IDE section there is the option to Clone in VS Code, this will launch VSCode, prompt where to save the repository locally, and open VSCode session with the newly downloaded repository open as a folder in VSCode. Looking at the screen shot below, you can also see the same feature is available with other IDE's:

For this guide you are going to use Git on the command line, this will allow you to understand the mechanics of what each command is doing as it will not be hidden by an IDE. To do this click the copy button (shown in red above).

Open a command prompt locally, and cd to the directory you would like to clone the repository into. Type git clone at the prompt, this is the git command for cloning, and then paste in the URL copied from Clone Repository above, this instructs Git where to Clone the repository from:
Hit return, and you will be prompted to enter a password. At the password prompt, paste in the Personal access token you saved earlier and hit return once more. If the credentials are correct, the Repo is cloned:

The highlighted section in white shows the password being accepted for the Repo and the four objects being cloned to the machine locally. You only created two files, a readme and .gitignore, why are there four objects:

If you list the contents of the directory structure using dir /b (ls on Mac), you can see the first object, the folder that contains the repository. cd into the repository folder and list the contents once more, the items listed are the second and third objects, the two files you created in the Azure DevOps portal. Altering the list command slightly to output all files and folders using dir /a /b (ls -al on Mac), the hidden .git directory is displayed. This is the forth object and is where Git tracks the local changes. Note on a Mac the .gitignore will not be displayed on listing the folder contents without ls -al, it is treated as a hidden file.

Note - the first time you connect to your repository on a windows OS you will be prompted to enter the credentials you sign into Azure DevOps with:

Once successfully entered, the Git credential manager creates a Personal access token for you and caches it locally. You can view this by going back to the list of Personal access tokens in Azure DevOps:

You will see a third Personal access token, the name of which has been auto-generated based on the machine name Git generated it from. You also have default Scope, which may need to be edited.

You now have a locally cloned repository which has no changes from that on the server. You can check this using the git status command:

The highlighted section shows that there are no changes. Next you'll look at adding changes back to the locally cloned repository and then into the Azure Repo.

Step 3 - Saving changes with commit and push

When you work with code within a repository, the repository needs to be instructed that you want changes you have made to the code within it to be committed to the repository. The process of committing saves your changes to the repository, tracking the changes and linking them to your credentials. It is best practice to group your commits into work items, such as a defect fix from issue tracking software, or a completed task from a sprint. This will keep the changes small, updating often, this will avoid conflicts when merging back with other changes. Until the point of commit, changes are not tracked in the repository, only on the local file system.

To see this in action you need to edit your local repository files, to do this you can launch VSCode from within the repository folder on the command line using the code . command:

VSCode opens with the dotnetcoredemo repository opened in the explorer view on the left hand side. Clicking on the readme.md opens the file in the editor:

Edit the header change the text to # Introduction to Azure Repos and save your changes. Switch back to the command prompt and run git status once more from within the dotnetcoredemo directory:

Git status has picked up that there is a modification to a tracked file on the file system and has displayed this, if there was more than one change, all changes would be listed here. At this point the repository is not tracking the listed changes, the notice that Changes are not staged for commit, indicates this is the case. To track the changes you first need to stage the changes. For this you need to issue the git add command. You can stage a single file using it's filename with the git add filename command or if you have more than one change to stage, you can use a full stop git add ., to add all changes. If you now re-run git status :

The filename is now shown in green, it has been staged and is ready to be committed to the repository to be tracked locally. Issue the commit command git commit -m "commit message", where the commit message describes the change, or details a work item such as a defect number:

The unique identifier for the commit is displayed first, along with a summary of what has changed. If you now issue a git status as shown above, you can see that your local repository is described as 1 commit ahead of the Repo is was cloned from, this is because you have committed one change since you checked out from the Azure DevOps Repo.

Your change has now been tracked locally, but you haven't updated the Repo to store the changes in Azure. To do this you need to use the git push command to push the committed changes from your local repository in to the Azure Repo:

You can see the git push command compressing the committed changes and pushing them to the Azure DevOps Repo. Once this process is complete, if you re-issue git status, the message Your branch is up to date with 'origin/master' indicates that the local and Azure DevOps Repo are back in synch.

Switch back to the Azure DevOps portal, this time click on Commits under the Repos menu item on the left hand side:

The Commits page shows the list of commits against this Repo, if you now click on the Commit text of the Updated the readme commit you can inspect the differences in the files between the two commits:

This view shows the original line 1, it is in red with the minus sign in front of it, and it's new text in green with the plus sign at the beginning. When there are multiple changes within a file, this view can be difficult to review, you can change this by clicking Inline diff to switch to the side by side view:

Next you will look at how to bring in committed changes from other users.

Step 4 - Updating Code with fetch and pull

Distributed version control systems such as Azure Repos enable teams of developers to work on code and commit changes at the same time. Therefore, there are times when you cannot be sure you have the latest version of the code. When this is the case, you will need to execute some Git commands to ensure you have the latest version in your local repository:

fetch - downloads the changes from your remote repo, but does not apply them to your code. This allows you to take a look at the changes before applying them.
merge - applies the changes taken from a fetch to a branch on your local repository. Once you have looked at the fetched changes and decided they are suitable to add to your code, you choose to merge.
pull - combines the above, does a fetch and then a merge.

To simulate another developer making a change and pushing it to the Azure Repo, switch back to the Azure DevOps portal, click Files under the Repos menu item on the left hand side, and click on the README.md filename to open the file in Preview:

If Azure DevOps knows how to display a filetype, such as Markdown, it will open in file preview, formatting the file appropriately. To edit the file click Edit top right:

Edit the file and change the heading Getting Started, click Commit in the top right, you will now be prompted to enter a commit message:

Enter your commit message and click Commit at the bottom, in the background Azure DevOps is executing the same git commit -m command you used in an earlier step. The difference being that Azure DevOps is committing the change to the Azure Repo and not locally. So if you switch back to VSCode and edit the README.md file, you will see that the heading still says Getting Started.

The local repository and the Azure Repo are now out of synch, to have the change reflected in the local repository you pull the changes to your local repository. This will execute a git fetch and a git merge:

The change made in Azure DevOps has now been pulled down to the local repository, if you switch back to VSCode, the change to the header line is now visible.

Step 5 - Pushing an existing repository from the command line

You've explored working with a repository created with Azure DevOps, by cloning that repository locally, pushing to, and pulling changes from the Azure Repo. What happens if you have already got a local repository and need to push that repository to a new Azure DevOps project? To simulate this you need to intialise a new git repository locally, you will then add a README to this repository and push it to a new Azure DevOps project.

Initialising a repository creates an empty repository using the same method utilised by Azure DevOps in Step 1. Both of these processes both use the git init command. When executing the command locally, it must be executed within folder that does not already contain a git repository, however, the folder does not have to be empty:

The process here is to make a new empty folder using mkdir on the command line, cd into that folder and then execute git init. The section highlighted above shows the Git repository being initialised and then dir /a /b (ls -al on a Mac) to display that the repository is empty, apart from the newly created .git folder.

Next, you need to add a file to simulate code being present in the local repository. Execute code . on the command line to launch VSCode within the repository and then create a README.md file for the repository:

Enter some text within the file and save. Switch back to the command line and execute git status to verify that Git has picked up the change on the file system. Now execute git add . to stage all changes ready for commit, then commit the change using git commit -m and add an appropriate message:

You now need to create a new project within Azure DevOps, so switch to the Azure DevOps portal and click Azure DevOps top right to return to your Azure DevOps organisation, click New project in the top right hand corner, this opens the add project page:

The create project page displayed is slightly different than the one displayed for a new Azure DevOps organisation. You will need to enter the Project name, making it the same as the folder name of your local repository. If you scroll to the bottom of the page, you can also select Version control which always defaults to Git, but can be changed to Team Foundation Server. Click Create to create the new project. When the new project is created, click on Repos in the services menu on the left, you will see the same empty repo page as viewed in step 1. Scroll down to Push an existing repository from command line:

Here you can see the URL for the remote called origin. A remote repository in Git is a version of the project hosted either on the internet or on a local network, in the case of this guide, within Azure DevOps. Origin is just the default name for the URL, it's shorthand name. If you execute git remote from inside a repository, all remotes for the repository are listed:

You have a new locally intialised repository with no remotes, so none are listed at this stage. Switch back to Azure DevOps and copy the first part of the command for pushing an existing repository:

The remote has been added and re-issuing git remote lists origin as a remote. You now need to push your changes up to the origin, to do this execute git push origin master, this pushes all changes from the local master branch to the origin:

Switch back to Azure DevOps portal, click Repos and then Files on the services menu for the localgitinitdemo project, the Repo now reflects the repository pushed up from local:

Step 6 - Working with GitHub

Azure DevOps Repos is just one of the Git backed source control systems where repositories can be stored remotely. GitHub is also a Git backed system, it was a forerunner to Azure DevOps Repos. GitHub is the industry standard collaboration platform for open source software projects, enabling developers to contribute to code repositories all over the world. In this Step you will look at working with GitHub repositories using Git.

Sign into GitHub with the credentials used to create the GitHub login in the prerequisites step:

This is an empty project, there are no repositories in it yet. Click New top right to add a new repository:

The content this page requires is the same as that of an Azure Repo. Enter a Repository name, leave the repository at it's default of Public, you can also initialise a README.md and a .gitignore. The extra dropdown allows you to choose an open source license for this repository, which is very common on GitHub. Click Create repository, the repository is created and the repository page is automatically loaded:

Scrolling down through the repository page, you can see git commands for creating a new repository or pushing a new repository from the command line. These commands are exactly the same as those for Azure DevOps, the difference is the address of the remote, which is pointing at your GitHub repo. To explore this start by initialising a local repository:

The commands used here are identical to that of Azure DevOps, first create an empty folder with mkdir githubdemo using the same name as the repo you created in GitHub. Next cd into the folder and initialise with git init. Use the echo command to quickly create a README with a single header echo # Welcome to GitHub >> README.md (echo "# Welcome to GitHub" >> README.md on a Mac). Execute git add . and git commit -m "message" to stage and commit your changes locally. You are now ready to push changes to the GitHub repository, however, even though it is a public repository, you still need permissions to access the repository. Switch back to the GitHUb repository in your browser, click on the profile icon in the top right, and click Settings:

Scroll down to the bottom of the Settings menu and click Developer settings. In the left hand menu of the Developer settings page is Personal access tokens. GitHub uses a similar mechanism to grant access to it's repositories as Azure DevOps. Click Generate new token:

Once again you can see the similarity with Azure DevOps Repos. You need to enter a Note to say who the token is for and grant the Scope, in this case ticking repo to grant access to public and private repositories with this token.

Scroll to the bottom of the page and click Generate token, to generate the token:

The generated token page warms you that you must make a copy, as the token cannot be recovered. Once you have taken a copy of the token, navigate back to the repo page and take a copy of the first command for …or push an existing repository from the command line*. Switch back to your terminal window and execute this command inside the folder where the git init was run and README.md file created. This creates a remote called origin which points at your GitHub remote. Now you can execute a git push origin master to push the local master branch to your remote:

Note - on a Windows OS you will be prompted for your github credentials, when the page is displayed enter your username and password as if you were logging into GitHub on your browser:

Once you've entered the credentials, if you switch back to GitHub in your browser and navigate back to the Personal access token page, you'll see that entering the credentials has created it's own Personal access token, setting a scope of Repo and Gist:

This will only happen on Windows. On a Mac you will be prompted for your username, and then a password. At the password prompt you must enter the Person Access token that you generated.

Once you have your changes pushed up, switch to the repository view in GitHub in your browser to check the changes have pushed successfully:

The commit message entered is displayed against the commit, and the test added to the markdown can be seen within the README.md

Conclusion

In this article, you've explored how to work with Git and Azure DevOps / GitHubs respositories. How to setup an empty repository, then push a current code line to it, or create from scratch within the portal or on the command line. You've simulated updating your code following a change from a team member, and how to use access tokens to push code from a command line or IDE.

The next part of this three part series will take you through setting up a workflow which enables the same code lines to be worked on by a team, merging changes, whilst keeping code quality and standard compliance in check.

Forem: Nicole Stevens

Running MacOS on Windows 10 with WSL2, KVM and QEMU

Windows Terminal - port a scheme from iTerm2, customise your own scheme and use a custom font

Introduction

Pre-reqs

Windows terminal settings and using a readily available scheme from GitHub

Setting up your own theme and converting one from iTerm2

Creating your own Scheme

Conversion from iTerm2

Conversion with PowerShell

Conversion with Go

Changing your font

What about a funky prompt!

SSH With Windows Terminal profile

Create an Azure Pipeline for a .NET Core Webapp and configure for Continuous Integration (CI)

Table Of Contents

Create an Azure Pipeline for a .NET Core Webapp and configure for Continuous Integration (CI)

Introduction

Prerequisites

Step 1 — Setup the ASP.NET Core Webapp project

Step 2 - Understanding the build and publish process

Step 3 - Create a build pipeline

Step 4 - Manually running a pipeline

Step 5 - Configuring for Continuous Integration (CI)

Conclusion

Working with the Feature Branch Workflow and Pull Requests

Working with the Feature Branch Workflow and Pull Requests

Prerequisites

Step 1 — Configuring branch policies in Azure Repos

Step 2 — Integrate Azure DevOps with Azure AD

Step 3 — Pushing a local feature branch to Azure Repos

Step 4 — Deleting a feature branch

Conclusion

Getting started with Git and Azure DevOps

Table Of Contents

Introduction

Prerequisites

Step 1 — Setup a Repo in Azure DevOps

Step 2 - Cloning the Azure Repo

Step 3 - Saving changes with commit and push

Step 4 - Updating Code with fetch and pull

Step 5 - Pushing an existing repository from the command line

Step 6 - Working with GitHub

Conclusion