If you work with an open source project, or by other means want to share your project with unknown people, GitHub is a great place to store source code. It does not provide any support for building, versioning or deployment, so you have to set these things up somewhere else.
You can use either Team City, Jenkins or TFS 2015 to host your own build service without so much trouble. If you are not so keen on running your own machine, you can use an online service instead. One of those is Visual Studio Online (VSO), which is my favorite in this case since it’s build agent:
- Integrates well with GitHub.
- Is free to use for 60 minutes each month.
- Is easy to customize for those special needs that you almost always have.
With the new functionality introduced for TFS 2015, VSO build has become very capable. For a description about what is available read Why You Should Switch to Build VNext, by Colin Dembovsky.
To demonstrate the ability for customization and doing something completely different in a build, I will use my PowerShell repository on GitHub as an example in this post.
Connecting VSO to GitHub
If you do not already have an account on visualstudio.com, create one now. Once logged in create a team project representing your GitHub repository.
In TFS a team project is a container where repositories, work items, source code, and builds are kept.
Head over to Builds and create a new build definition. Enter your connection details under the Repository tab.
Authorization to GitHub is made through an access token, that can be generated under personal access token on GitHub.
Build Your GitHub Repository With VSO
Since I used a PowerShell repository as an example there is nothing to compile in the build, but the purpose is only to run a series of tests.
To my knowledge, the most used testing framework for PowerShell is Pester. The hosted build agents does not have the Pester module installed. So to be able to run the tests, Pester will first have to be installed. I have written a script for this, and which is explained in more detail later in this post.
What is performed by a build is configured under the build tab, by adding one of the available build steps. Running a series of Pester tests can be done by executing a PowerShell build step.
To have the build kick off automatically when changes are pushed to the Repository, configure the build with a Continuous Integration trigger. Use Filters to select what branches will trigger a build. But you can also build your GitHub repository with VSO manually by pressing the Queue build button.
How to Run Pester in VSO
Build Result and Lessons Learned
As can be seen, the build failed because 10 tests failed.
This was actually the first time I executed the tests on another machine than my own. It turned out that some tests weren’t as independent as I thought. And some could not even execute on a Windows Core, which is the operating system used by the VSO hosted build agents.
Running tests automatically is a good idea, and in this case I learned the hard way that it’s best to start using an external build service from the very beginning. Even for a scripting language.
One of the modules in my PowerShell repository uses web scraping to get information from a web page, and if the layout changes to much it will no longer work. To alert me when it has broken it is convenient to schedule a build every night and set up an email alert for failed builds.
VSO and TFS 2015 provides a way for you to present a badge on a website to tell whether you build passes or not.
To enable this feature you can check the Badge enabled checkbox under the General tab of a build definition. When you save you will get an url to a SVG image that looks something like this:
Go build something!