At it simplest, a build pipeline is a workflow or process followed the same way after every execution of a certain trigger. It's a way of ensuring code is written correctly, does what we expect it to do, and can be deployed successfully to an environment.

To an IT administrator, the concept of a build pipeline may be completely foreign. Building software is for developers, right? Wrong! Building application software is for a software developer, but writing code to automate software deployments, infrastructure provisioning, and so on is the domain of an IT professional. More specifically, the build pipeline concept falls into the blurry DevOps zone.

A build pipeline's job is to automate the huge majority of tasks it takes to package up a bunch of code, run tests on that code, optionally create the test environment, and deliver that code to the test environment. If you'd like to read more about build/release pipelines, I recommend checking out the article The Anatomy of a Release Pipeline.

There are many ways to create a build pipeline and many different tools such as Jenkins, Bamboo, Team Foundation Server (TFS), AppVeyor, TravisCI, and more. However, what if you're just getting a feel for how a build pipeline should work and simply want to create a super-simple, custom one on your own? You can with PowerShell.

As I mentioned earlier, a build pipeline starts with a trigger. This is typically a code check-in by a developer (continuous integration) or could simply be manual trigger. To keep things simple, we're going to define our trigger as me running a script to kick it off.

Next, we'll also need to define what's going to go on in the build pipeline. The build tasks that execute are completely up to you. But usually, those tasks include code testing, some kind of packaging routine like compiling code into an executable, creating a folder structure for testing, deploying code to a test environment, and finally performing tests on that environment.

To keep this simple, my build pipeline is going to consist of:

  • A development PowerShell script (the code I'll be working on)
  • Pester unit tests for my script
  • Deployment of the PowerShell script to my test environment
  • Pester integration/acceptance tests for the environment we'll apply the script to

If the PowerShell script I'm developing works correctly, I should be able to copy this script to a server and run the script, which will then create a file. I know it's not sexy by any means, but what it does really doesn't matter. A build pipeline is all about delivering the functionality that the code performs to an environment in a highly tested, predictable manner.

First off, here's the simple PowerShell script I'll be using as my code example:

Next, I'll create a Pester unit test for the script ensuring it called Add-Content as expected.

Now that I've got the unit test created, I'll build my acceptance test to test the result of the script after it runs.

I'll then start creating my build script, which will have all the steps in my pipeline.

At this point our little build script/pipeline is complete! My project folder now consists of the DoStuff.ps1, DoStuff.Unit.Tests.ps1, DoStuff.Acceptance.Tests.ps1, and BuildScript.ps1 PowerShell scripts. At this point, I simply need to trigger the pipeline, which in our case will just be me running the build script manually.

Triggering the build pipeline

Triggering the build pipeline

You can see we can now be sure my DoStuff.ps1 script is fully tested and reliable! We ran unit tests on it, deployed it to a test server, actually ran the script, and then verified its results.

Now this is taking PowerShell scripting to the next level! Imagine now if we were checking this script into source control, which automatically kicks off the build script when a change is made. We can be sure that for every iteration of the script, its functionality will undergo testing to the utmost degree.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!

  1. Techliet 2 years ago

    Can you create a database site with this.


  2. Line 4 of the first code block I think is just a normal line of text.
    So the code block should close at line 3 and another one should be open on line 5.

    It's a good article by the way!


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account