Learn to use psake, a PowerShell build automation tool, to build a self-contained, reusable, continuous integration pipeline. You will learn how to write a psake script from scratch, package the script and the required tools as NuGet packages to increase reusability, and how to integrate your script with TeamCity to build your ultimate continuous integration pipeline.
Fabien has been in the web development industry for over eight years, all of them working with Microsoft technologies. More recently, he has been busy building microservices in .Net and is passionate about continuous delivery and automation.
Introducing psake Hi this is Fabien Ruffin and welcome to Continuous Integration with psake and TeamCity: Getting Started. Have you ever wondered how you could simplify a continuous integration workflow to build a generic and portable process, which would be reusable across multiple projects? In this course I will show you how to build your very own reusable, generic, and self contained continuous integration pipeline with psake and TeamCity. Let's go and have a look at what I'm going to talk about. In this first module I want to start out by looking at the advantages of such a solution as we go through the goals of our continuous integration pipeline. I then want to go and give you an overview of psake, which is the main tool we will be using to build this pipeline. We will also take some time to get familiar with psake in a demo in which you will build your first psake script. During the remainder of the course, we will actually go through and set up psake and TeamCity with a couple of different sample applications. So this is going to be a very practical course that will cover a range of different topics from build to unit tests, test coverage, packaging, and finally how we can use the power of NuGet to nicely package our continuous integration pipeline for easier use. So let's go and jump right into it.
Running Tests Our build path line is starting to come together. We now have psake building a solution with MSBuild and TeamCity is hooked up to our version control system and running our psake script. In this module we'll focus on one of the critical paths of our build pipeline, testing. Let's have a look at what we are going to do in this module. We'll start by looking at the current output of our build and learning about how MSBuild can help organizing the files for easy consumption by our test runners. Given that one of the goals of this build process is to be generic, we will integrate with three of the most popular unit testing frameworks available today, Nunit, xUnit, and MSTest. This will give our process a very significant reach and increase reusability. We will take this opportunity to learn more about psake in the process. More specifically, you will learn how to conditionally run a task and how you can include external scripts to your build process. We will then finish off by integrating the whole lot to TeamCity and report our test results to it, so they can be easily accessed from the test dashboard. So looking back at our build process overview, we're going to tackle the first half of step 3 and we will leave out the test coverage for the next module.
Gathering Test Coverage Metrics Our build script is now able to run unit tests and we can fail a build when the test doesn't pass. The natural progression is to find out how much of our code is covered by unit tests. So let's jump right in and look at what I'm going to talk about. OpenCover is one of the last open source test coverage tools for. NET. It's popularity is increasing and in this module I will show you how to use OpenCover from a psake script to generate an XML coverage report. XML reports are useful for tools, but not so much for humans. Which is why we'll look at how to generate HTML reports from the OpenCover XML report by using another Open Source tool, ReportGenerator. With this information available, I will show you how to report your test coverage metrics to TeamCity by using TeamCity's service messages and custom reports. Finally, to ensure that the quality of our application stays as good as when it was first written, I'll demonstrate how to get TeamCity to fail a build when test coverage drops. So looking back at our build process overview, we're now going to work on the second half of step 3 and add a good coverage analysis to our pipeline.
Packaging Our build pipeline will now let us know when the quality of our applications is not up to scratch. So we are finally in a position to package our applications and get them ready for deployment. Let's go ahead and take a look at the overview of what we're going to cover throughout this module. We are going to start the easy way, by packing our applications as zip files. There are a few different ways we could do this, but we are going to use 7-Zip for the compression. The reason for using 7-Zip as opposed to say, the PowerShell community extensions, is that the 7-Zip command line tool is available as a NuGet package and therefore will be easier to integrate with our build process. Then we will step it up a notch and enable the ability to package our applications as NuGet packages. NuGet packages are now used more and more often by deployment automation tools, such as Octopus Deploy as it allows to not only package the applications, but also embed some metadata, which can be very useful at deployment time. We will then look at our class library project and how we can also package it as a NuGet package as part of our build process. Finally, for the last step in our build pipeline, we will clean up our artifact directory to keep only the files we care about. So looking at our build process overview, we will tackle the last two steps, package and clean-up, during this module. Okay, let's get started.
Working with NuGet Our build script is now complete and we can now compile our code, run our tests, generate code coverage reports, communicate coverage statistics back to TeamCity, and package our applications. We have also reached most of the goals we set out to achieve at the beginning of the course and now build pipeline can run locally on our dev machines as it is 100% self contained. However, we are still missing an important part of the story, which is to make this build process easily reusable. In this module, we will solve this problem, so let's have a look at how we're are going to do it. One of the big pinpoints with our current process is setting up the MSBuild build targets as this is a very manual process. We have three different targets for our test projects, one for our applications, and one for class libraries, and it can be a bit difficult to remember which one goes where and how to set them up with our projects. Another relatively big issue is that as it stands our psake script is not easy to upgrade. Imagine you have a few different solutions, all using the same build pipeline, and you want to make a few changes to the script. At the moment, you will have to duplicate your changes in each solution, which can be time consuming. To solve these problems, we will use NuGet once again. We will start by looking in detail into what NuGet package is made of before packaging and distributing our build targets and the build scripts. We will then move on to TeamCity and see how TeamCity's native NuGet support can greatly simplify the task of creating and distributing NuGet packages. We will finish off by putting those new packages to use in our sample solution and set up a build configuration template in TeamCity so the full process can be reused. Let's get started.