In this blog series, I want to take you through the process of setting up Azure DevOps and using source control to provision and maintain a virtual server environment in Microsoft Azure. The technique used here can just as well apply to any other cloud or on-premises environment.
The reason I am putting together is that I have found lots of material online about the subject, but I haven’t found any useful guides that explain the process from start to end. If you read this guide and find anything I can do better or something I have missed, please let me know so that I can update the guide and make it better.
Before getting into the real guide I just want to put in a disclaimer. I am an Ops guy doing a lot of scripting, so this is my attempt to share how I use source control and pipelines. I am not an expert, but trying to use good tools to help me in my automation work.
Let’s get into the exciting part of actually settings this up.
The first thing to do is go tohttps://azure.microsoft.com/en-us/services/devops/ and sign up for the free Azure DevOps service. The service is free for up to 5 users with the following limitations;
- **Azure Pipelines:**Includes the free offer from INDIVIDUAL SERVICES
- **Azure Boards:**Work item tracking and Kanban boards
- **Azure Repos:**Unlimited private Git Repos
- **Azure Artifacts:**2 GB free per organization
- Load testing (20,000 VUMs/month)
The sign up is easy, follow the guide from Microsoft, and you should be good to go.
Next thing I do is to creating a new project; Click “New project” in the top right corner of the front page.
I give the project a name and select private or public for the project. There are some advanced functions to control which type of source control to use and which project management model that will be used. I will leave those as standard since I use Git, and the project model isn’t a topic for my private development projects.
The next thing I like to do is rename the repository for the files I will be developing. Click the wheel in the lower-left corner and then clicking “Repositories”.
Right-click the repository, which in my case is “Guided project”, then click “Rename project”.
I will change my repository name to “Azure infrastructure resources” and click on “Rename”
The reason I rename my repository is that I tend to have several repositories in the same project. I am doing this to keep my code separate when I feel like it is two different parts of the projects but still needs to be in the same project. Later in this guide, I will create a second repository, so at that time, it will probably make more sense.
To keep this guide simple to follow, I will close the first part here. Part two will be covering boards and how to use them.