Jan 19, 2021

Welcome to Architect Tips, presented by Clear Measure, a software architecture company. Empowering .NET development teams to be self-sufficient, able to move fast, deliver quality, and run their software systems with confidence. Make sure to subscribe on YouTube or your video podcast feed. If you have a question for the show, send them to architecttips@Clear-measure.com and the next tip could be yours.

Hello and welcome to Architect Tips. Today, I want to talk about the essentials of a private build and a lot of people are trying to do continuous integration but they only have a manually, triggered or an automatically triggered compile process which is only one of the steps of continuous integration. Continuous integration has three steps. Actually, the first is the private build. We do it locally. The second, the commit phase,

has the integration build where you run on a build server and that's the bill for your team. In the third step is the first deployment and fully deploy test suites. And so, the continuous integration has those main three stages and a lot of the tooling makes it easy to have an automatically triggered compilation process but a lot of people leave it there. So I want to talk about the first step which is not even on the build server yet, but it is just something you have for the application itself. Whether it's a visual studio solution representing a big application, or whether it's a solution representing a small microservice that’s just a stand-alone Azure function or just an individual job of some sort. And so let's go through this and this is a build script that you can actually follow the structure. If you're familiar with my book, .NET DevOps for Azure, you can find the build script in the download tools in the download files there but I'm just going to go all the way to the bottom. 

This is just straight power shell. At the bottom, we have a function called CI build, and then right above it, we have private build. And so if we look at what it's doing the private build, we have some chocolatey packages that this application needs. And so we use the build script to install those directly so that somebody can just clone the git repository and immediately run the build as opposed to get the Clone the git repository, then install this, then install that. Then configure this, then configure that and you know, we want the experience of, you know, the big things like you have to have the right visual studio version installed on the computer, clone the git repository, run the private build. So we're installing the chocolaty packages then in it essentially does clean compilation. That's running .NET, .EXE, or msbuild then we're going to do some environment set up in this application. And a lot of times, we have a SQL Server database or database of some sort. So we need to create a shell of a database locally and then after that, which is after unit tests to run, then we run the integration test that typically do a lot of data access as well as other things. So, that's the structure of it. And then I'm going to go back up to the top and kind of walk through each one of these individually. 

So, up at the top again, this is just straight Powershell and all of the uniqueness. You could literally copy this power shell file. And there are so many, go back to 2005. I think almost every application and client that I have worked with has taken this structure, this layout, this template of a build script and used it in their applications. Now, of course, in 2005, it was not running with cruise control .NET. But essentially the same you need a script file that does the stuff, you pull all the unique stuff up into properties at the top. And so you see the project name, my project and later on, you'll see that we can just use that name and then put a .SLN on the back of it. Now we have our Visual Studio

Solution file. We have a source directory where the unit tests are, where the integration tests are, where the acceptance tests are. Most applications have some sort of user interface project and whatever, whatever you need the database path, where you want your build artifacts to be, where you want the test artifacts to be the path to your database, migration tool whether using roundhouse, alias SQL, and and even pulling a version number directly from a build server. You see, we're having some data parameters pulled in Via environment variables but if the variables aren't there, meaning it's running locally, we just default it to something, but if it's running on the team's build server, then it's pulling in variables through the environment. So we see in it, all that's doing is getting rid of artifacts from previous build runs. You see? We do a .NET clean, we do a .NET restore. That's essentially cleaning everything out. Then the compilation Project. Now, this script has you really want to copy this script and use it because over the years, all the command line switches for .NET .EXE are absolutely tuned and running in unit and I know the getting started samples online. They don't have that level of detail, but if you want, if you want a very tuned build with all of the command-line switches that you want to use, then just get this build script and copy it. So that's our

compilation process then we need to run our unit tests. We don't need to do any other environment setup like setting up a database because unit tests don't require database. They only call code that stays in process. So we call .NET .EXE, then test. And again these are command-line switches is the way you want to call it and then after that in the order. I know in order we have integration tests but actually the order of running, we're going to do a migrate database local which is calling our database, migration tool and is going to create the database schema from the folder where the scripts are in after that, then we're going to call integration tests which is going to call the other test library with in-unit and it could just as well be X unit and .NET .EXE Test, acceptance test is not used for a private build. It's used in the integration build for the fully deployed version so on the private we'll just skip that and then essentially we're done. But we have some other power shell functions in here. Because we want to use this exact same build script in our integration build process on the build server whether using your own build server or as Azure pipelines and so we have pack UI and pack admin. Those are two top-level processes that need to be deployed and then pack DB and we pack it in nuget packages. Octopack Octo .EXE is actually an open-source project from Octopus Deploy that is the best at packaging where Deployable applications into properly Formatted NuGet files and whether you using octopus deploy or not, this tool is indispensable. So that's the structure of, that's the structure of a private build script and you can see how when we come back to calling private build and it just runs it. So I hope this helps. Get this template, use it. But even if you don't use this format, make sure that you have an independent script at the top at the root of your git Repository that can set up the local environment and build and run all of the tests and validations that you have for that particular application. Whatever format you use, make sure that you have that asset for your development team. So that you can move fast, and increase and sustain quality and ultimately run your software systems with confidence. Thanks, and if you have a question that you'd like on Architect Tips, Just send me an email at ArchitectTips@clear-measure.com

Thanks for watching Architect tips. If you would like, help improving your team speed quality or software stability. Send us a note to architecttips@Clear-measure.com on behalf of everyone at Clear measure. Thanks for watching and may God bless you.