Getting started with Azure DevOps Repos

10 min readOct 29, 2020

Every engineer has been there — the code lost, the computer dead, the project gone. Serenity gone. No more calm. Hours spent rescuing and recreating. Pain, Agony, all the rest.

What if there were a better way? What if we could simply and easily take a backup of the code, store it in a repository, and allow other computers easy access, through a credentialed system?

Even if you aren’t planning on growing your company from just you to 500,000 worldwide, it’s still worthwhile.

With Azure DevOps, you can keep a local copy, as well as have a cloud backup. Kind of like Dropbox, or Box.net.

So how is Azure DevOps better than just backing up your files?

Versioning: Automatically create various versions of your files. Is your code currently working? Do you want to keep that version working while you refactor it? (Or in engineer words, break the code for a while until you figure out how to make it work again?) Create a new branch in your repo and work on that until it works again.
Notes: When you decide that your code is working (or whenever), you can put code in your repository with notes attached. These notes can specify what is going on, what your thoughts are, and what exactly you wish to do. Now, when you get back from that long vacation, you can easily see just why you were doing what you were doing, and possibly just how wrong (or right!) it was.
Pipelines: In addition to your local build environment, Azure DevOps Repos can automatically maintain a build environment in the cloud — ensuring that you can always have a working copy, even in the case of a computer loss. (Heck — you can work entirely off the cloud build environment if you like!) Note that pipeline can actually integrate with a local machine — so you could store your secure keys in your org, but manage signing code with the Azure DevOps Repos.
Sharing: Because Azure DevOps Repos are part of the “cloud”, that nebulous structure we talk about all the time, you can easily share code, you can share deliverables and binaries, you can share packages.
Integration with Your Tools: Azure DevOps Repos are built on standard GIT semantics, so they easily integrate with pretty much every tool known to man. Don’t believe me? See: https://docs.microsoft.com/en-us/azure/devops/repos/get-started/what-is-repos?view=azure-devops#connect-your-favorite-development-environment
Integration with Other GIT services: You aren’t limited to JUST Azure DevOps Repos — you can host your code in other services. Thus, you could use GitHub, and still utilize Azure DevOps Pipelines.
And something we’ll touch on in later articles, integration with other Azure Tools. Your machine learning tools will pick up the repository and branch, allowing you to easily track experiments, for instance. Your pipelines can call other Azure tools. Your billing is all in one spot.

All in all, there’s a lot of advantages to using Azure DevOps Repos. Surely, it must be very complex to setup though!

Not at all.

Much of this is contained in the excellent documentation on Azure DevOps Repos site — but I’ll go over some specific things. https://docs.microsoft.com/en-us/azure/devops/repos/?view=azure-devops

I prefer working in Linux, it just makes me feel better, so I’m going to use WSL2 for this. You can work in your own environment, and we’ll just have to agree that it doesn’t really matter, as long as we can get our work done. I’ve got enough to argue about right now with other people. Trust me, I’m writing this from 2020, and it looks like civilization may be destroyed by murder hornets or flying sharks.

Assuming though that we survive 2020, here’s how to setup WSL2. It will require at least Windows 10, something I hope you’re already running. Seriously. Please don’t tell me you’re on Windows 7 or something. In that case, go install something functional, like Linux. I highly recommend Ubuntu LTS (whatever the latest is, 20.04 as of this writing) as your first WSL2 distro. The reason for this is 2 part:

Ubuntu is extremely easy to use. Most Linux distributions these days are fairly easy to use, but Ubuntu has a great user community. Lots of great questions on the forums at https://ubuntuforums.org/.
LTS stands for Long Term Support. It walks a line between constantly updating and not having the latest tools. LTS will be there for a number of years, and modern tools will be available on it. This means that you can continue to follow new tutorials, without constantly breaking your setup by the updates. After all, we’re here to have fun and get stuff done, not necessarily learn how to be a Linux Admin. (Which is its own brand of fun, so I’m not putting that down!)

Install Windows Subsystem for Linux (WSL) on Windows 10

Windows Subsystem for Linux has two different versions to choose between during the installation process. WSL 2 has…

docs.microsoft.com

Once you’re done with that, let’s get a functional terminal emulator. Download the new Windows Terminal Emulator from the Windows Store: https://www.microsoft.com/en-us/p/windows-terminal. Since we are going to spend a lot of time in the terminal, let’s make it easy to open up a terminal right to our WSL Ubuntu distro.

Hit the arrow at the top of your Windows Terminal toolbar.
Click settings, which, as of this writing, brings up a nice notepad editor with some JSON. Not the nicest setup, I know, but it’ll work … for now. I expect better though!
Look for the line with the name of the distro you chose. For me, it’s Ubuntu-20.04, as shown in the picture on the left.

Finally — change the GUID of the default profile to match the guid displayed in this stanza:

Save and exit the editor. Next time you start the Terminal, you’ll get Ubuntu! (Or whatever you picked here.)

Lastly, let’s setup Visual Code: https://code.visualstudio.com/ This is probably the best editor out there right now. It’s crazy how well it works. Microsoft has done a great job really walking through use cases and ergonomics. In addition, there’s extensions for everything — emulating VIM, Emacs, Your coffee maker, interfacing with Azure, Your iPhone, you name it. Seriously, the extension marketplace is kind of overwhelming.

When you install Visual Code, make sure you check the following boxes:

These will help us later — we can easily open code files. With the new WSL2 integration with the File Explorer, this will make getting into our WSL2 git repos very, very easy!

Once we have Visual Code installed, we are going to want to setup WSL and Visual Code to work together.

Open up Visual Studio Code, and you’ll see this box in the bottom right:

Click ‘Install’ — it’s that easy.

This, when complete, will bring up the Store page for WSL, complete with an overview of the entire extension. It also contains a link to the tutorial — again, Microsoft has put a lot of time and thought into this: https://code.visualstudio.com/docs/remote/wsl-tutorial

Now that we have all our tools in place, let’s setup GIT\Azure DevOps Repos for our WSL setup.

First, you’ll need to signup for a new Azure account. If you’ve already done, this can skip it. Head to: https://azure.microsoft.com/en-us/free/ and sign up for a free account. You’ll need and email address, a phone to text for verification, and a credit card number. The card won’t be charged, but it’s required anyway.

That’s it! Wasn’t that easy?

For a full list of what you’re getting free, see: https://azure.microsoft.com/en-us/free/free-account-faq/

In another article, we’ll talk about how to manage payments, bills, budgets, etc in Azure. It’s very rare you’ll be charged if you’re just developing casually.

Now that we have a new Azure account, let’s get a repository going!

Start by going to: https://azure.microsoft.com/en-us/services/devops/repos/ and click the ‘Start Free’ button.

Unless you’re migrating a huge project, you’ll be fine with a free account. Essentially, you’ll have 1 job or task running at a time, and you get 1800 minutes of total time a month. If you want to make things faster, you can add parallel time and tasks, but you can always decide on that later.

Once you’ve clicked the ‘Start Free’ button, you’ll be greeted with a quick region selection. Select your region, then click ‘Continue’.

Now, we’ll need to select and create a project. You can have as many of these as you like, so for now, let’s call it ‘My First Project’. Select whether you want it public or private, and let’s click ‘Create Project’.

For your new project, it’s time to tell Azure (Hey Azzzuurreee!) where your code will live. I’m currently keeping all my code in Azure Repos Git, just because it’s here.

Click the Azure Repos Git, and then you get taken to a confusing screen where Azure wants you to select a repository. You don’t have any yet — just projects. So for now, click the Overview on the left.

Now, click the ‘Manage your services’:

Scroll down a bit, till you see the Azure Repos:

How to turn on Azure Repos

Ensure that the button is set to On.

This will give us the ability to create a new repository for us to hook into.

Now, when you head back to the main Project Page, you’ll see a new Service in the left hand column:

It is with this, that we will begin hosting our code here.

Once you click the Repos header, it will expand into a lot of info.

The basics of Azure Repos

This is the basic link to Azure Repos. A couple of things to note here:

ssh access will allow you to cache your keys, so that you don’t need to always log in. (Note — there is an outstanding issue around ssh keys with a passphrase: https://code.visualstudio.com/docs/remote/troubleshooting#_resolving-hangs-when-doing-a-git-push-or-sync-from-wsl)
https access requires you to login, although you can then set a long timeout before you have to login again. Or, you can set a credential helper.

Go ahead and set ‘ssh’ access.

Time to generate keys. We’ll need these — they essentially tell the server (using a public key) that it’s really us, and we can access the source. (We can get into a discussion of Identification, Authentication, Authorization some other time, k?)

Open up your Windows Terminal (hit the Windows key, and then type terminal, then hit enter when Windows Terminal is highlighted.)

Terminal will default to our WSL setup. See? Easy!

See? 2 new files — one with the public key!

First, to setup git repos, let’s run ‘cd ~ && mkdir gitrepos’.

Second, let’s setup Git, in your terminal:

git config — global user.email “youremail@domain.com”
git config — global user.name “Your Name”
git config — global credential.helper “/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-manager.exe”

Third, run ‘ssh-keygen’. It will ask for a passphrase, for now, leave it blank.

Finally, run ‘cd ~/.ssh && cat id_rsa.pub’, and you’ll see a couple lines of output. Use the mouse to highlight, then hit — ctrl+shift+c to copy it.

Back on your Azure DevOps, hit your profile Icon, and select ssh keys.

In the top right, click ‘Add Keys’. Copy and paste the output of id_rsa.pub, and give it a name, like “My Public Key” or something.

You can now test your connection in your terminal:

ssh -T git@ssh.dev.azure.com — should return ‘shell access not supported’.

Note — at this point, I needed to restart Visual Code to have it pick up the new config. Not 100% sure why.

Finally we get to clone our repository.

Back in Visual Code, we’re going to click the source control icon:

Once you’ve clicked this button, you’ll get prompted to input a path. In Azure Repos, you’re looking for this bit of text — in the main repository screen, where we were just a little bit ago.