Recently Microsoft announced a rebranding of Visual Studio Team Services (VSTS) to Azure DevOps and as a big fan of Azure, I wanted to check out if the changes were just a new name or if it’d progressed to be a little more welcoming.
I say this because as someone with limited experience using VSTS, I always found it to be a little intimidating so tended to use simpler services like App Center for building my apps and Trello for my Kanban boards. I hoped that the change would include some UI enhancements that could help me ease into DevOps rather than being thrown into the deep end.
Thankfully the team has done some fantastic work in making Azure DevOps easier to get started with and I’ve now adopted it for managing my personal long term project.
In this post, I’m going to discuss how and most importantly why I’ve configured Azure DevOps to allow me to have confidence in the code I’m writing.
In this post, I’m going to discuss how and most importantly why I’ve configured Azure DevOps to allow me to have confidence in the code I’m writing.

One huge solution to rule them!

The project I’m working on is big, or at least it’s going to be massive. Right now its just a minimum viable product and it contains 17 projects, which I originally put into a single Git repository. This worked well for the beginning of the project but as I started to add more and more projects it became difficult to keep things separate.

It’s for this reason that I decided to create two separate solutions to make a clear separation of concerns. Ultimately I’ll probably end up splitting up Lighting Core Solution further as the project develops but for now I think two solutions provides me with enough separation.
Simple Archteicture.png

Smaller Solutions

Having two separate solutions rather than one beast makes my life significantly easier for ensuring that the Lighting Core code doesn’t become too sticky with my UI and vice-versa. It does, however, cause me some difficulties in how I should reference the dependancies as I don’t have an easy way to ensure that the UI project has all the code required to build. To solve this, I went ahead and moved all my code in Azure DevOps as a stepping stone towards fully embracing the tool.

devops1

Private Nuget Feed

With all the code hosted in Azure DevOps I have a one-stop shop for my projects development.

I went ahead and defined build processes and hooked them up so they’d be triggered everytime I pushed code to the master branch.

devops2

The build steps is very simple. I restore packages, build and then pack up the DLLs ready for release.

devops3

I’ve defined separate pack tasks for each project that I wanted to turn into a Nuget package. This task handles packaging up the results from the build ready for releasing either publicly or privately.

devops4

I’ve then defined the most basic release pipeline possible to take the results of the build pipeline and push to Nuget.

devops5

Because I’m releasing the packages privately, I host them in Azure DevOps and can access them in Visual Studio with minimal configuration required!

devops6

Wrapping up

This blog post covers at a very high-level how I’ve gone about setting up the basics of a continuous integration and deployment system for my pet project. If you want to learn how you can also configure your own CI/CD system then checkout the great tutorial over at Microsoft Docs.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.