What is build definition?
A build definition is a representation of the automation process that you want to run to build and test your application. The automation process is defined as a collection of tasks. VSTS and TFS have a number of tasks to build and test your application. A build definition describes the details of what your build is supposed to do, and when it’s supposed to do it.
Build and Release are two of the DevOps services in VSTS and TFS that help you manage continuous integration and delivery of your applications.
Visual Studio Team Services (VSTS) and Team Foundation Server (TFS) provide a highly customizable continuous integration (CI) process to automatically build your Web, Mobile or Desktop application whenever your team pushes or checks in code. You can also Schedule builds on a specific date or time, recurring builds or manually queue a build.
You can add build tasks for .Net, Java, Node, Android, C++, xcode applications. Similarly, there are tasks to run tests using a number of testing frameworks and services. You can also run command line, PowerShell or shell scripts in your automation pipeline.
A basic build definition consists of 3 steps or build tasks which can be used with the Visual Studio template (this template requires Visual Studio be installed on the build agent):
- Visual Studio Build: This step builds the solution in the $(build.sourcesdirectory). This is the Source directory with the letter “s” under the Agent’s work folder. TFS gets all the files under this directory and builds the application under the bin folder. Provide the path to the solution that requires to be built. In case you need to build a web application, fill the msbuild arguments with: /p:DeployOnBuild=true /p:PublishProfile=<name of Publish profile>. Make sure the Publish profile is checked-in.
- Copy Files: This step copies the files from the source directory described above to the Artifacts Staging directory $(build.artifactstagindirectory) with the letter “a” under the Agent’s work folder. The Files Published for the Web Application can be found under bin\$(BuildConfiguration)\Publish folder.
- Publish Build Artifacts: This step Publishes the artifacts in step 2 to the Shared folder for which Network share path requires to be provided. Appropriate permissions are required on the folder to the same user that is running the Build Agent Service on the Agent machine. You can Publish the files copied in step 2 from the Publish folder above to the Network share path for continuous delivery pipeline.
This tab lets you specify the Mappings under the Source “s” folder on the Agent machine as to how it should manage the downloaded source files locally. You can map each Server paths with a local path e.g. one Server path may be mapped to Application files and other Server path may contain PowerShell scripts which may need to be run in a different build task.
This tab specifies some of the required demands that are defined as capabilities on the Agent machine like:
- vstest etc.
You can specify additional demands like choosing a specific agent by adding a demand as “Agent.Name”.
The Build Number format specifies the name of the folder under which queued build will be placed.
This tab holds some predefined system variables and link to the entire list of it. You can also add your own variables which can be used in the build definition.
Specify whether to schedule the build, build with each check-in or with gated check-ins.
Lets you specify the duration until which you’d like to keep the queued build.
Shows the log of any changes made to the Build definition by which users and when.