A couple of months ago I first wrote about an open source project that I started called MSBuild.Sdk.SqlProj. Since then it has gained some traction and I’m happy to say it is probably the most succesful open source project I’ve launched ever. So I though this would be a good time to give an update on the project and share some of the things that are new. If you’re unfamiliar with the project I recommend reading the announcement blog post first.

At my current employer, R&R Workforce Management, we’ve done a pretty big investment on Microsoft’s SQL Server Data Tools (SSDT) to manage our database changes. We made that decision when we migrated off of the Oracle database onto SQL Server which is quite a few years back now. At the time it was probably the most mature tool available that allowed us to version control our database changes much like we version controlled all our source code.

This is the third post in my series on building a pull request bot using Azure Functions. If you haven’t read my previous posts I strongly recommend doing so before diving into this post. Remember that this series is a part of the Applied Cloud Stories initiative. Part 1: Introduction Part 2: How it works Part 3: Operating it In this post I want to give you a feel for how we operate our pull request on a daily basis.

This is the second post in my series on building a pull request bot using Azure Functions. If you haven’t read my first post I strongly recommend doing so before diving into this post. Remember that this series is a part of the Applied Cloud Stories initiative. Part 1: Introduction Part 2: How it works Part 3: Operating it In this post I’ll dive into the details of how the bot actually works, from receiving notifications from Azure DevOps to managing state and posting comments back to the pull request.

About 2,5 years ago I was talking to my fellow team members about some of their challenges. At the time we had recently switched from TFS Version Control (TFVC) to Git, which obviously introduced quite a few changes in the way we worked. For example, we introduced pull requests as a mandatory step in the development flow in order to increase awareness and code quality. However, we found that some things that would need to happen for every pull request weren’t being done (or not done properly) which weren’t always caught by reviewers either.

This post is part of a series: Part 1: Introduction Part 2: Third party dependencies Part 3: Mechanics of porting Part 4: Deployment and packaging options If you haven’t read any of the previous posts I recommend you do this now to get some context that I’ll be referring to in this post. If you have, continue on with the nitty gritty details of porting an app to ASP.