{"id":2079,"date":"2015-09-09T00:00:00","date_gmt":"2015-08-24T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/writing-build-vnext-tasks-for-visual-studio-online\/"},"modified":"2021-04-27T13:41:10","modified_gmt":"2021-04-27T13:41:10","slug":"writing-build-vnext-tasks-for-visual-studio-online","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/devops\/database-devops\/writing-build-vnext-tasks-for-visual-studio-online\/","title":{"rendered":"Writing Build vNext tasks for Visual Studio Online"},"content":{"rendered":"
\n

Background<\/h2>\n

Visual Studio Online (VSO) is perhaps Microsoft’s worst-named tool. It’s NOT hosted Visual Studio. It’s hosted TFS 2015. As with Team Foundation Server (TFS), it’s a source-control server, a build server, and a project-planner. VSO lacks a few features of on-site TFS, but essentially it’s the same. Microsoft is now adopting a ‘cloud-first’ attitude – building new features into VSO first and then releasing them on-site – so VSO is certainly no second-class citizen.<\/p>\n

TFS traditionally uses XAML definitions to define a build process. These are written in Visual Studio using a Workflow-style visual editor. This is a powerful but notoriously difficult process. Very few people bother, usually relying on the default templates.<\/p>\n

Microsoft has created a new way of writing build process for VSO, currently known as ‘Build vNext<\/a>‘. This new method will be very familiar for people working with build-systems such as Bamboo, TeamCity or Jenkins. On the VSO website, you create a build definition then click to add a few tasks (e.g. msbuild, run a command, start an Azure website, etc). You fill in the details of these tasks, then hit Queue Build. On the website you also setup options like build-triggering and build-variables.<\/p>\n

\"2272-VsoSQLCIBlog_Screenshot1.png\"<\/a><\/p>\n

Microsoft has declared that all new projects should use Build vNext, so they clearly consider it the future of TFS.<\/p>\n

Writing TFS Build Tasks<\/h2>\n

What I want to talk about today is writing VSO Agent Tasks. These tasks are the fundamental steps in a build vNext build process, such as running MSBuild, deploying an Azure Cloud Service, or running a PowerShell Script. There are currently about 30 built-in tasks.<\/p>\n

At Redgate Software, we make tools for SQL Developers and DBAs. Redgate SQL CI enables you to build, test, synchronize and publish databases. It’s a command-line tool, so can be invoked as part of a build by adding a PowerShell or Command Line step that invokes something like:<\/p>\n

sqlCI.exe Build \/scriptsFolder=WidgetShop\\Database\\Scriptsfolder \/packageId=WidgetShop \/packageVersion=1.0 \/temporaryDatabaseServer=(localdb)\\v11.0<\/pre>\n
This is a bit verbose, but  perhaps tolerable. But what if I also want to add error-checking or some  PowerShell? And re-use it all over? And what happens if the command-line changes  slightly, and I have to update command-line invocations all over the place?  Writing a custom build-task is a solution.<\/p>\n
By building a task, you’re  creating a reusable build component that can be shared with anyone using your  technology.<\/p>\n
Before writing this  article, I created four build tasks corresponding to the four Redgate SQL CI  actions. This makes it much nicer to use from VSO:<\/p>\n
 \"2272-VsoSQLCIBlog_Screenshot2.png\"<\/a><\/p>\n
Adding a build task to  the build<\/p>\n
  \"2272-VsoSQLCIBlog_Screenshot3.png\"<\/a><\/p>\n
A build process with six  steps<\/p>\n
Writing a TFS Build Task<\/h2>\n
There  are currently about 30 built-in tasks, which are all   open-source in GitHub<\/a>.  At the time of writing, this GitHub repository is the primary place you should  go for guidance and documentation. These is currently no formal documentation,  so you’ll have to rely on scraps of information in this repository (and articles  like this one!)<\/p>\n
A task  primarily consists of three components:<\/p>\n