Microsoft has completely rewritten the build server in Team Foundation Server and Visual Studio Online. The new tool completely eliminates the massive XAML-based Windows Workflow files that were used as build definitions.
Major concerns that led to this rewrite include:
- Inability to add post-build custom scripts without learning Workflow Foundation
- Can’t build iOS apps because it doesn’t work on non-Windows platforms
- Can’t build Java programs without learning both MSBuild and another technology
- Can’t edit build templates unless everyone is on the latest version of Visual Studio
- No more XAML. The new build definition no longer uses Windows Workflow files with their massive amounts of XAML.
- Cannot edit build definitions on the web or on non-Windows machines
In order to address these concerns, Microsoft’s new build server follows these key principles:
- Don’t create a new build/automation DSL. If you are using MSBuild, Ant, etc. then you should be able to just use MSBuild, Ant, etc.
- Non-Windows platforms need to be supported equally.
- The build system needs to be easily extensible.
- Logs shouldn’t be hidden
New Features in Visual Studio Online Build
Build definitions can be created and modified directly in the browser. You no longer need to use Visual Studio just to tweak a build.
Build definitions often need access to secrets such as production passwords and security tokens that you don’t want everyone to know. To protect these, you can now store encrypted variables with the build definition.
Build definitions are no longer directly defined by a branch. After you create the definition, you can tag which branches that will be built using it. Each branch can have its own trigger (CI, daily, etc.).
When using workflows such as git-flow, you will often end up with lots of feature branches. Under this new model, you can use wildcards in the build definition. For example, you can say that any branch matching “feature-*” will automatically be compiled and the tests run while “qa-*” is only built daily.
The build tool can directly run PowerShell scripts. This is especially important with Azure, where deployments are mostly handled via PS files. Build is aware of Azure subscriptions, which makes it easier to ensure the deployment is run in the correct context.
Once a website is deployed, build automation can kick off a “Quick Perf Test”. Based on the load testing features in Visual Studio/TFS, this will perform a basic smoke test to ensure the deployment was successful.
Cross Platform and Testing
In addition to building on OS X, the build automation can now run tests in that environment. Test results are produced in a JUnit format, which can then be imported back into the build server and displayed.
Xamarin Test Cloud is also supported by the build automation. You can select test details such as which devices/operating systems you are interested in directly from Visual Studio Online.
VSO is agnostic when it comes to unit test frameworks.
Cross platform build agents are based on Node.js and xplat.
Extensibility
Key information such as build numbers are exposed as environmental variables so they can be easily read in any scripting language.
Build agents are automatically updated as new versions of the build tools are released.
All out-of-box tasks will be open source. It has not been determined if third parties may contribute to OOB tasks.
Tasks for Windows are written in PowerShell. For other platforms, xplat and JavaScript are used.
Architecture
The new build server works side-by-side with legacy XAML based builds.
There is no longer a single physical controller for build agents. This removes a rather important failure point.
Agents are grouped into pools. Each pool has collections assigned to it and are secured at the pool level. This eliminates the need to manage individual build agents.
Security
Currently the build agents are run in a shared process. This means that one failed build can corrupts the entire build agent. And failure could be something that seems innocuous such as an open file handle.
With the new build agent model, each build is run in its own process. When a build is complete, the process is completely eliminated and a new process is created for the next build.
A relatively unknown security hole in most build systems is the “unit test backdoor”. Developers can write a unit test that captures sensitive information which can then be used by the developer to access information that should be restricted. To help mitigate this risk, build agents are given a time-limed token that expires once the build is complete.
For more information on the new build automation features, check out the Channel 9 presentation What's New for Build Automation in Team Foundation Server and Visual Studio Online.
