Reputation: 1507
We're working on migrating from TeamCity to TFS. I've built a couple of build projects in TFS and have found that using a build script seems to be the most flexible, but is also difficult to get them to work correctly. Finding the latest msbuild for example is especially tedious. Using the built-in tasks are easy, but keeps you limited to what that particular step allows. Like the dotnet core step missing the pack option.
I'm not finding any guidance as to which way works better overall, whether using a build script in the build definition vs a bunch of build steps.
Is there any best practices/whitepapers available that are relevant to VSTS or TFS 2017 or does anybody have any guidance as to which way to go?
Upvotes: 0
Views: 800
Reputation: 30372
It's based on the specific requirement. TFS build system with the goal of making it genuinely cross platform and much easier to work with. There are buil-in tasks and you can use them to greatly improve the way you put together and customise your own build system.
A task is the building block for defining automation in a build definition, or in an environment of a release definition. A task is simply a packaged script or procedure that has been abstracted with a set of inputs. We provide some built-in tasks to enable fundamental build and deployment scenarios.
In addition, Visual Studio Marketplace offers a number of extensions; each of which, when installed to your account or collection, extends the task catalog with one or more tasks. Furthermore, you can write your own custom extensions to add tasks to your account in VSTS or your collection in TFS.
Actually you can combine the script and the build-in task to make the build system most flexible. For example, you can use script with below task introduced in your build definition:
Below articles may helps:
Upvotes: 1