|I have long had an interest in the DevOps side of the software development lifecycle. As much as I love to write software, I love to build and deploy it too. After all, it doesn't really matter how great your code is, if people aren't using it then it's an irrelevance. The process of building and deploying software has long been a passion of mine. I love to setup and configure build processes. DevOps automates and simplifies the process by which software can be deployed onto user's machines. From the developer checking in their code, the process of versioning the software, executing and publishing unit tests, analysing code coverage, and depoying the final article onto a release server are all part of the DevOps process. These can (and should) all be automated. The developer shouldn't have to worry about any of this (unless like me, they actually enjoy setting up these processes). I have previously used CruiseControl, TeamCity, Team Foundation Services and most recently Azure DevOps.
We have recently begun the task of re-building our next generation mobile app. For this we are using Xamarin in conjunction with Azure services. We currently use Team Foundation Services (TFS) for all of our DevOps processes. This is a brilliantly simple, yet very flexible and powerful build process tool. I haven't found anything that I haven't been able to do with it. For our new project though, I wanted to make use of Microsoft's replacement to Visual Studio Team Services (VSTS) which is now branded as Azure DevOps.
This seemed the perfect time to start using Azure DevOps - with a new project. I don't have any intentions of migrating our existing projects, so it would require a new project to allow me to get my hands on Azure DevOps.
First off, for anyone who has previously used TFS or VSTS, Azure DevOps (which is really a re-branding of VSTS) should look and feel very familiar. As it's name suggests, it is powered by Azure infrastructure meaning it will scale up and out as your build process grows.
We have separated our new mobile app into two distinct solutions. One is the Xamarin Forms app, and this will unsurprisingly contain the actual app itself. The other will be the Azure backend server that will provide all the functionality to the app (business logic, notifications, service requests etc). It is this latter solution that I have been focussed on moving into Azure DevOps. At the time of writing, I have setup the pipeline to include:
- versioning the assemby
- restoring the Nuget packages
- building the solution
- executing the unit tests
- publishing the code coverage
There are literally hundredes of in-built tasks for building, testing, packaging and deploying your software. You also have access to the Marketplace where you can find hundreds more tasks developed by the community. Even big players such as JetBrains have free tasks available in the Marketplace. So if you can't find the task you want, you can probably find one that matches in the Marketplace. If not, you can always develop your own and publish it in the Marketplace yourself.
My first impressions of Azure DevOps is that it's quite simply a brilliant tool. It reduces our reliance on our on-premise infrastructure and allows us to fully build and deploy our applications on rock solid infrastructure in the Microsoft cloud. If you currently use TFS then it's worth spending the time to explore Azure DevOps. Unless your business already has a large investment in IT infrastructure, you'll be very hard pushed to beat the Azure stack. If you're currently using VSTS then you'll be automatically migrated to Azure DevOps anyway. Even if you don't currently use TFS or VSTS, it doesn't matter. You can build, package and deploy your application using Azure Devops regardless. It has support for every platform and technology. So whether you're brand new to DevOps and don't have anything currently configured, or if you're currently using an alternative, it's worth checking out Azure DevOps anyway.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare