Last week I introduced a client to the new TFS 2015 build system. They happily started experimenting with it, but soon ran into a bit of a cryptic error message saying “Unable to load task handler … for task …”.
The new build system which was introduced in Visual Studio Team Services (VSTS) and TFS 2015 has been gaining more popularity lately, and (in my opinion) rightly so. It simply works far better than the old XAML builds. I’ve been converting quite a few XAML based builds to the new build system. While doing this, I (inevitably of course) came across quite a few custom build workflows and tasks. Some of these were easily converted to build tasks that are available out-of-the-box, while others required some custom tasks. When creating a custom build or a custom build task, you’ll at some point need some build-specific information. This is where environment variables become necessary. Since I wasn’t too familiar with the concept (I’d heard of them, but never really used them) I decided to dig a little deeper.
[Update 2015-08-12] Microsoft has just made a new command-line utility called “tfx-cli” available which allows you to create, upload, delete and list build tasks. You can use that, instead of the “TaskUploader” described in this post. I’ll leave this post up here, since the part about building the tasks is still useful.
“tfx-cli” is distributed through npm and can be found here.
A nice walkthrough by Jeff Bramwell can be found on his blog here.
OK, one more post for today… This morning I promised you I would show you how to build Java code on a Linux build agent using the new Build.vNext build system in Visual Studio Online. This post is to deliver on that promise. Being a Linux and a Java newbie, I thought it would be a complex task. As it turns out, it isn’t. Once you have all the bits in place, the great new build system makes it easy to create a build definition that compiles the code. Actually, I even stuck some unit tests in there and got the test results to publish to VSO.
In the past few months Microsoft has made it very clear that they are no longer a Windows-only company. Things like Xamarin integration, the new multi-platform ASP.Net 5 and the cross-platform .Net CLR are all results of that new strategy. This opens up all sorts of new possibilities for developers who were previously tied to a single platform. Exciting times are coming!
The new build agent for the Build vNext system is another example of this cross-platform strategy. The new build agent is actually based on Node.js which means it should run on any platform that supports Node.js. This includes Linux. So, I decided to give that a try. And guess what? It works! Running a Microsoft build agent on Linux, I think that’s pretty cool!
And, the new build agent is fully open-source! You can have a look at the code on the VSO agent GitHub page.
Create a build agent pool
While technically it’s not required, I think it’s nice to create a separate build agent pool for Linux build servers. Log in to your VSO account and click the gear icon in the top right to get to the settings page. Then go to the “Agent pools” tab and click “New Pool”.
We’ll need to set some permissions before we can add and run our new agent. Ideally, you would create a new (service) account for your agents. Unfortunately, I don’t have one available so I’m going to use my personal account. First, we need to enable alternate credentials for the account. Log in to VSO using your account and open your profile settings.
- Agent Pool Administrators: allows adding agent to pool
- Agent Pool Service Accounts: allows the agent to listen to the build queue
Create a server
Next, we need a server! The easiest way to get one is to create on in Azure. I decided to go for the newest Ubuntu version currently available.
For now, I chose to use password authentication. If you want, you can create a key file and use that. It’ll take a few minutes before the server is ready. To log in we’ll need an SSH client. A great one for Windows is PuTTY. Go ahead and download that if you didn’t already. Start PuTTY, and type the hostname for your server. Then, click “Open” to connect.
You’ll get a message asking you if you trust the computer you’re connecting to. Click “Yes” and you’ll be presented with a login prompt. Login using the credentials you provided when creating the virtual machine.
Because of a naming conflict with another program called “Node”, the default installation in Ubuntu installs Node.js as “nodejs”. However, the build agent script expects to find a “node” executable… To overcome this problem, the “nodejs-legacy” package was created. Install it by typing “sudo apt-get install nodejs-legacy”.
Install the agent
Next order of business is to install the agent. As with TFS, the total process is split up in two parts: first we install the software bits, and then we run the configuration. To install the software bits we can use npm. Type “sudo npm install vsoagent-installer –g” and hit enter. That will pull the latest version of the installer from the repository.
We’re almost there… The only thing left to do is configure our agent. The agent installer allows us to easily create multiple agents on a single server. Each agent will run inside its own folder. So, first we need to create a folder. Type “mkdir linuxagent1” to create one and then cd into it with “cd linuxagent1”.
This installs the agent into the directory you just created. Now we can start it up and connect to VSO! Type “node agent/vsoagent” to start the configuration. Enter your credentials (these are your alternate credentials!), your VSO URL, an agent name (optional) and your pool name (“Linux” in my case) and the agent should start up!
Note: the agent is now running in interactive mode. This means that when you close your session, the agent will terminate. While this is fine for testing and demonstration, it’s not so nice for production. Currently, the agent doesn’t support running as a service on Linux. The development team is working on that. In the meantime, you can use this trick to run the agent in the background: after starting the agent, hit “Ctrl+z”. This will stop the process and display a job number (1 in my case). Then, type “disown –h %1” (where 1 is the job number). This ensures the job is not stopped when you log out. Finally, type “bg 1” (again, 1 is the job number). This will start the process again, this time running in the background.
You can check your new agent by going to the “Agent pools” administration page on VSO and checking your queue there. Your new agent should show up there. And, it’ll identify itself as a Linux server!
In this post, I’ve shown you how to run a Build vNext agent on Linux and connect it to VSO. While we haven’t actually done anything useful with it yet, it does demonstrate the true multi-platform direction that Microsoft is headed in. In theory this should allow us to build a Java application on Linux for example. While I’m thinking about this my fingers are itching to give that a try… More on that in a later post!
I’m always up for trying new bits of technology. And to be honest, as a consultant I think it’s an absolute necessity to know what is out there. Fortunately, exploring new technologies is fun!
Recently Microsoft has made Build.vNext publicly available on Visual Studio Online. You can read Brian Harry’s blog post here. Build.vNext gives us a much simpler build system than the old Xaml workflow based system. It’s also fully extensible (more about that in a later post) and fully web-based. Also, the infrastructure has changed: instead of the Build controller – Build agent(s) architecture there is now the concept of build agent pools. These pools can be shared across collections, so you no longer have to deal with a separate controller for each collection.
Visual Studio Online provides a hosted build agent pool. This is great because you don’t have to deal with your own infrastructure. However, if you need to customize your build agent then you’ll have to install your own agent, which you can then connect to VSO.
I thought I’d give that a go and try to build a MVC 5.0 (which is also in preview) app while I’m at it. MVC 5.0 is included with the Visual Studio 2015 preview. In this post I’ll show you how to configure a build agent and connect it to VSO. In a next post, I’ll walk you through the process of creating a vNext build definition for building a MVC 5.0 app.
To get started, we need a server with Visual Studio 2015 RC installed. The fastest way to do that is to get one from Azure. Log in to http://manage.windowsazure.com and create a new virtual machine. There is a template available for the Visual Studio 2015 RC.
In the next couple of screens, choose a username and password for logging on to the machine. The other options can just be left as defaults. Once your machine is completed, connect to it using Remote Desktop.
Once logged in, I want to create a local user for running the build agent under. Go to Server Manager, Tools, Computer Management and open the “Users” node under “Local Users and Computers”. Now right-click and select “New User” and fill in the details.
Now that we have the prerequisites in place, we can get on to the more interesting stuff. First, we have to download the bits for our new build agent. On your new server, open up a browser and log on to your VSO account. Click the little gear icon on the top-right to go to the VSO Control Panel, then go to the “Agent pools” tab and click the “Download agent” button.
This should give you a zip file which contains everything you need to run a VSO build agent.
Download and extract the zip file to your local machine. I put mine in “C:\VsoAgent”.
Now all that we need to do is configure our agent. This is done using PowerShell. Open up a PowerShell window in Administrator mode by shift+right click on the PowerShell icon and selecting “Run as Administrator”.
Then, change to the directory where you downloaded the bits.
Set the execution policy to “Unrestricted” so that you can run the script to configure the agent.
Now, run the configuration script for the agent. It’ll ask you a bunch of questions regarding the configuration of the agent. You can customize if you want to, or just accept the defaults. In my example, I’m configuring the agent to run as a Windows Service so that it will start up when the server starts. Make sure to connect to your VSO account (don’t include the “/DefaultCollection” bit in the URL!) and provide the local account you created to run the agent if you choose to run the agent as a Windows Service. If all goes well, you’ll get a message telling you that the configuration of the agent succeeded.
If you look in the VSO Control Panel, you’ll see your shiny new agent listed, along with it’s capabilities.
That’s it! Your build agent is now ready for use. Happy building!