Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / DevOps / continuous-build

How to run a local Continuous Integration build via a Visual Studio shortcut key

0.00/5 (No votes)
7 Jan 2016CPOL3 min read 4.5K  
Article discussing how to run a local Continuous Integration build via a Visual Studio shortcut key, with a focus on PSake

I worked on numerous projects in the past where developers will compile the code, run the tests, and, confident that everything is going to be fine, push their changes to the CI server, only to watch the build go red because the build script used for CI performs some different tasks than simply compiling and running tests, and the developer's changes have affected them in some unforeseen way.

I've tried a few build languages over the years, mainly NAnt, MSBuild and Rake, but my head has been firmly turned recently by a relative new kid on the block, namely PSake. It's basically a Powershell build automation language that doesn't suffer from the slightly unwieldy XML syntax that my previous favourite, MSBuild, is encumbered with. I'm not going to delve too deeply into the wonders of PSake in this post. I will leave that for another time. The technique I'd like to highlight here is one that I set up as soon as I am able to get my greasy mitts on the automated build script for the project. I've mentioned PSake because the examples I show here will be with respect to that language, although the technique can be applied to any build language that you can execute from a command prompt.

What we are basically looking to attain is the ability to execute the build script from within Visual Studio by pressing a shortcut key. The output from the build run will show up in the Output window inside Visual Studio. This technique is obviously no substitute for running a build on the build server itself, but it far closer to that process than simply compiling and running your unit tests.

To start with, we need a build script, which, for our example here, lives in our solution, within build/build.ps1. I won't go into detail about the steps that the build performs, but it simply cleans and compiles the code, runs the unit and acceptance tests and then performs a few deployment type activities.

First, create a batch file to execute the build script

To run the build within Visual Studio, the first step is to create a batch file in the root folder for your solution that executes the build script. Mine's called buildandtest.cmd and it looks like this:

psake build\build.ps1 -framework 4.0  -taskList ReleaseBuild

Second, create an External Tool to run your batch file

Now that we have an executable batch file that we can call, we need to call it. To do this, from the Visual Studio Tools menu, select External Tools...

We're going to add a new tool called Build. The Command should be the full path to the batch file (in my case it's "C:\Levelnis\Projects\Levelnis\build.cmd" and the Initial directory is "C:\Levelnis\Projects\Levelnis". Leave Arguments blank and ensure that Use Output Window is checked.

Last, assign a shortcut key to the External Tool, sit back, have a brew, etc.

Before you leave the External Tools window, ensure that you move the new tool up so that it's the first item in the Menu contents window. We're now halfway there and can access our new batch file from the Tools menu. The next step is to link that tool to a shortcut key for ease of execution. Back to our friendly Tools menu, this time selecting Options > Keyboard (within the Environment option group). You are basically looking to assign a shortcut key to Tools.ExternalCommand1. I tend to select Alt+1 for this. If you start typing ExternalCommand into Show commands containing, select Tools.ExternalCommand1, type into Press shortcut keys and click Assign. OK that to close the window and you should should be able to run your build by pressing Alt+1

In case, like me, you have more than one build configuration that you like to run, the ExternalCommand options have a numeric indexer, and the number corresponds to the position of the Tool in the External Commands list (which is why I suggested moving the item to first place in the list and linking it to ExternalCommand1). You can have multiple tools mapped to multiple shortcut keys.

View original article

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)