This is one of those posts I never thought I’d write. Visual Studio Online has grown in leaps and bounds over the past year. It is the de facto solution I use in the majority of my projects because it is free to set up, features free build minutes every month, and even five free licenses to develop against. That is a very low cost to entry considering you can provide unlimited stakeholder access to manage your full application lifecycle from requirements and sprint planning down to deployments.
The only special set-up within my project is that my packages.json file has a special post-install script to make it easier to install Bower components in the build environment:
"postinstall" : "node_modules/.bin/bower install"
For Visual Studio to access my repository, I need to create a special access token. I tap Settings:
Then choose Personal access tokens:
I give the token a meaningful name and keep the defaults for just repository access. After clicking Generate Token I get a special token I can use in Visual Studio Online.
After I copy the token, I’m done on the GitHub side of things.
Visual Studio Online
Next, go to your Visual Studio Online account. If you don’t have one, I suggest you sign up for free. It’s quick and easy. You’ll need to create a project (there are instructions when you sign up) and now you’re ready to go.
I use a project to organize my weeks. As a practice manager for my company I’ve got a fairly full schedule, and the Kanban board lets me continually prioritize my time and focus and ensure nothing gets forgotten. From the main page of my project, I’ll tap the Build tab.
From there I’ll tab the Actions button to add a new build definition.
I choose the Empty template to start with.
By default I end up on the Build tab. The first thing I want to do is navigate to the Repository tab instead.
Here I can change the repository type to GitHub and paste my access token. After it is pasted and confirmed, the list of repositories is available so I choose qorlate and the default branch. I’m not concerned about cleaning the build environment as I know it will fetch everything needed. Now the build definition is linked to my GitHub repository. I can navigate back to the Build tab and add my first build step.
For the first build step, I want to run NPM Install and ensure the grunt command line interface and Bower are both configured.
The working directory defaults to the root of my project, which is fine. If you have a sub folder in a larger project, you can specify the correct directory here. Notice I just add the commands I’m going to pass to the arguments tab.
Next, I add the same build step with no arguments. This will automatically install any dependencies for the project. You can drag and drop build steps in the UI to determine the order. Now I have the step to install grunt and bower, and the step to install dependencies:
To run the grunt task I have to use some magic. As of this writing there isn’t a built-in build step for grunt (but there is for gulp, in case you prefer to use that). So, I’ll add a Command Line step instead and specify the path to the grunt command line interface. I renamed the step grunt build to make it clear what it’s doing.
Note that if you are running the build on your own host (I’ll share that later) you will want to specify the path on your build machine to the installation. The arguments are:
This will build and in my project I have the output going to a folder named build. So, I add a Publish Build Artifacts step and indicate where those artifacts exist.
Now I save the definition and tap the Queue build… button. You can also right-click on the definition to do the same. I’m going to use the Hosted controller that is provided for free. However, by default even though it has Node, it isn’t listed a capability as of this post. So, we need to fix that:
On the General tab for the build definition, ensure the default is Hosted and tap the Manage link.
This will give you a list of pools (outside of the scope of this post). Select Hosted and the default agent will be highlighted. Tap Add capability and add an entry to indicate the agent supports node:
Be sure to tap Save changes after making the change. Now you can submit the build. Ensure the Queue is Hosted and keep the defaults the same. If you get a message that the agents are not online (I assume this is a preview bug) just click OK to keep going. The build will queue and a console window will appear providing you step-by-step output from the build.
Once the build is done, you can click on the build name to view the logs and artifacts:
Using the explorer I verify the output was generated and packaged for me:
And that’s it! I’ve successfully used a free hosted controller to build my GitHub project using Visual Studio Online. Here’s where it gets really cool. If I’d rather do it on-premises, not a problem! I can navigate to the pool definitions and tab Download Agent for an installable that will let me use my on-premises agents to run Visual Studio Online builds.
You can have multiple agents with multiple capabilities and they will automatically synchronize with the VSO collection to perform their tasks. Now THAT is powerful! Are you interested in learning more about what VSO can do for you? Contact the experts and let us share how!