Im having a hard time figuring out what the best approach is when designing my build process. It seems Microsoft have turned things around (again).
I am using TFS 2015 and Visual Studio 2015. For earlier versions of TFS I have normally created custom code activities that I plug in to my build definition process file (xaml). I like this approach because it gives me great flexibility and enables me to code .NET classes. I used these guides:
https://msdn.microsoft.com/en-us/library/dd647551(v=vs.120).aspx
http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx
In TFS 2015 it seems that there is no documentation on how to create custom code activities. In fact, it seems that Microsoft have changed things and now focuses on scripting languages in stead of custom .NET code: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/steps/index.
I have created a custom code activity and it seems to be working in TFS 2015 (with a few hacks) so it is still possible, but I am nervous that this approach is no longer the way to go.
Can anyone provide information about what is happening here?
TFS 2015 introduces new builds, which are web- and script-based, and highly customizable. Meanwhile, TFS 2015 will continue to support the XAML Build templates and controllers.
The new builds are based on a different architecture and run on a completely different system. Currently, you can use both the new builds and agents alongside your XAML builds, controllers, and agents.
Which builds should I use?
If you are new to Team Foundation Server (TFS) and Visual Studio Team Services, you should use this new system. Most customers with experience using TFS and XAML builds will also get better outcomes by using the new system.
The new builds are web- and script-based, and highly customizable. They leave behind many of the problems and limitations of the XAML builds. For example, this new system embraces the diverse set of domain-specific languages (DSLs) that developers used to build the code on their dev machines. We expect this will reduce the chances of running into the "builds fine on my machine but not on the CI server" problem.
If you have heavily customized XAML builds and custom activities, you can continue using those builds until you are ready to port your business logic into scripts that can run in the new builds.
Useful articles for your reference:
- https://blogs.msdn.microsoft.com/visualstudioalm/2015/02/12/build-futures/
- https://msdn.microsoft.com/en-us/library/vs/alm/build/feature-overview
