Getting Started with Azure DevOps
Azure DevOps is a set of tools designed to help you take an idea, and turn it into a reality. As an individual, it gives you all the tools you might need to plan your project and as a team, it gives you the power to collaborate and drive the project forward.
Azure DevOps has been around as a service since 2013, when it was released as Visual Studio Online, later to be called Visual Studio Team Services, and finally being renamed to Azure DevOps Services back in September 2018. We often think of DevOps as a part of the process, Azure DevOps also provides rich and customizable dashboards that can provide insight to the wider project team, keeping them up to date on the work in progress and allowing them to focus on what really matters in order to deliver great features.
It should be noted that - while this is called Azure DevOps - you don’t need to be using other parts of Azure. In fact, this could be the only Microsoft product/service in your business. That fact is that Microsoft is sticking very true to their any developer, any language, any platform mantra.
What are the features?
There are five key features available in Azure DevOps: Boards, Pipelines, Repos, Test Plans, and Artifacts. You can use as many or as few of these as you like to help run your projects. The more of these features that you use together, the more joined-up things become, but the reality is that if you only need to use one of the features then you can do just that.
Let’s take a brief look at each of those features in a little more detail.
Boards provide you with a convenient way to track individual units of work. Depending on your type of project and phase you’re going to want to track issues and develop task backlogs. You’re also going to want to be able to plan, track and discuss these throughout the lifetime of the project.
Because of the way the work items have been baked into Azure DevOps, you can track them from idea through to production release. Boards are like the child of Git issues and Trello, and they carry some of ht better traits of their parents.
You can store various different tasks on the boards. These really include the kind of things you’re going to need to get your project up and running: issues, bugs, user stores, and so on.
This is the bit that for me springs to mind when I think of Azure DevOps. It's the ability to build, test and deploy with CI/CD. It works with any language, any platform and any cloud.
There are two main parts to play with here:
- Builds: Your build is where Continuous Integration is done. In here, you’ll be running a series of tasks to restore, build, and package up your application. As I’ve experienced with other CI servers such as Team City, you can set up common variables to be used across various tasks.
- Releases: These represent your Continuous Delivery side of things. You gain a lot of control in the releases with the ability to set up different stages, pre and post-approval, and approval gates.
Creating a new pipeline is a pretty straight forward affair. You can either use a fairly familiar drag-and-drop interface to populate a list of tasks or just dive straight in and start editing YAML files (which you can, of course, manage as code).
Both approaches offer some starter templates. When you’re starting a new build, for instance, Azure DevOps will assess your source code and try to suggest likely templates that fit your code. A huge collection of tasks are available out of the box, as well as tasks which are available in the marketplace.
If you do find something that it doesn’t do that you need, you usually have two options:
- If you can achieve what you want to do via the command line you can probably get is scripted in Azure DevOps.
- You can always write your own code to do exactly what is needed.
This is exactly what it says. If you’re already invested with another source control provider then you clearly don’t need/want to use this. GitHub is treated as a first-class citizen in Azure DevOps, so it’s just as easy to hook this up. But you can use pretty much any other source control you like.
If you do choose to host with Azure DevOps, then you can take advantage of unlimited, cloud-hosted private Git repositories with Azure DevOps - what's not to like?
Azure Test Plans
Azure Test Plans gives you a place to deal with all manner of testing. In here, we're not just looking at manual test plans, but also tackling manual test plans, exploratory testing and load testing. Having testing in one place with your storyboards, work items and code should allow for a more unified view of the full solution.
Create, host and share packages with your team, and add artifacts to your CI/CD pipelines with a single click. This is probably the second feature that I used in Azure DevOps while testing out a new build pipeline. It allowed me to upload all of my internal NuGet packages so that the build agent could get on with the task in hand.
Azure Artifacts allows the creation of both public and private package sources for npm, NuGet.
How much does it all cost?
For small scale stuff, it's basically free. If you start using it commercially, then the prices will start to appear and then go up. You can probably make some savings with the on-prem build agents but it's certainly worth doing your homework and reading through the service pricing.
Want to learn more?
I've only really brushed the surface with Azure DevOps and very much as a hobbyist at the moment (with a plan to making this part of my work process), there is naturally a lot more content out there if you want to learn more, including a multi-part series of videos called DevOps For ASP.NET Developers on the On .NET show on Channel 9. In this series, Abel Wang and Jeremy Likness run through how you can take full advantage of Azure DevOps in 8 easy instalments. I've got a link to all of them below too in a playlist called DevOps For ASP.NET Developers on YouTube, as the Channel 9 search/navigation can be a bit painful.