18 Feb 2018 | Visual Studio Team Services | ALM | Git
In my previous post I explored the the concept of treating build as a first class code citizen and how to automatically setup up an YAML based continuous integration (CI) build in Visual Studio Team Services (VSTS).
At the end of that exercise I was curious as to how VSTS handles build definitions when you throw branching into the mix. I could not find much information on the topic, so I thought I might try it out myself.
Prepare the project structure place the you build definition
.vsts-ci.yml in the root of the repository. Read my previous post for setting up an exported CI build.
Add an echo step so we can uniquely identify this build branch.
Commit changes to the
master branch and push it to the remote repository.
Verify that VSTS picked up the build and provisioned the CI build as expected. And that it triggered an initial build.
Verify that our echo statement worked.
Now let's update the build trigger to include all feature branches we create. Edit the build definition and navigate to the triggers tab add the following branch filter:
features/*. This means that the build would trigger on each of the
feature/ topic branches.
Navigate to the triggers tab and add a new branch filter.
Save the changes.
Next, create a new topic branch and switch to it. I am going to call it
git checkout -b 'features/complex-feature1'
Push the new branch to the remote server.
git push -u origin 'features/complex-feature1'
Verify that the build definition got triggered against the new branch.
Now let's make a change to the
.vsts-ci.yml. In order to keep things simple, I am just going to update the echo statement with the branch name.
Once again, let's commit and push the changes to the remote server.
Verify that a new build was triggered.
Confirm that the branch specific version of the build was executed.
This confirms that VSTS honors and executes the appropriate build definitions on the appropriate branch. Super cool!
The ability to branch build definitions gives team members the ability to customize and test build changes in isolation. It also minimizes the disruption to on going development until the changes are ready to be merged and shared with the rest of the team.
It doesn't seem to be possible to setup path filters from the YAML file. That being said, it can still be setup by editing the build definition after the provisioning.
This can be done by navigate to the
Triggers tab in the build definition and adding the path filter.
In the above example, I want to make sure that the CI build does not trigger when I make changes to the support tools.
Schedule builds also needs to be setup in a similar fashion to path filters.
What happens when you have multiple
yml files within a single repository? I hadn't even considered this until I stumble across it in the documentation.
Consider an example where the project already contains your wired up CI build but you'd like to use the second dedicated build for your production releases.
This is certainly possible - if VSTS finds a a file named
.vsts-ci.yml in the root path then it attempts to wire it up as a CI build automatically, but the additional builds needs to be setup manually.
Start by creating a new build definition from within VSTS and choose
YAML as the template. Confirm the selection by clicking the
Next, click the ellipsis button
... and select the path to the YAML file and click
OK to confirm.
Once saved, you can trigger the build as you would any other.
I can also confirm that VSTS treats YAML builds as regular builds and they can be used as the source for your release definitions.
So the changes YAML file itself is tracked by
git, but does VSTS track the changes we do to the build definition after provisioning? Yes, it does. Under the covers, it looks like VSTS sets up an json-exportable definition of the build. This is not a replication of your
YAML build tasks, but rather maintains everything thats not configurable in the
A history of all changes done to the definition can be viewed and compared from the history tab.
I, for one, have become a fan of YAML builds and can't wait for this feature to come out of preview and become a permanent.