Tuesday, January 15, 2008

What is new in TFS 2008: More Details - Part2


Continuous Integration builds –Supports the creation of build triggers that allows you to configure exactly when Continuous Integration builds should be started. For example, you can set a trigger so that every check-in starts a build, or you can set up a rolling build so that builds will start no more often than every X minutes.
Support for build queuing –Supports build queuing and queue management. This is especially useful for Continuous Integration as multiple check-ins may queue up multiple builds.
Scheduled builds –Supports scheduled builds, which can be configured to start at specified times based on your organization’s requirements.
Drop management –Supports drop management, which gives you the ability to set policies for when builds should be automatically deleted.
Specify build properties - Allows you to specify what source and versions of source should be built along with other build properties for a build type. There are many more exposed properties for customizing a build. Additionally, MSBuild command-line parameters can be passed when queuing builds.
Extensibility of build targets –Improves extensibility of the build targets. For example, you now have the ability to easily execute targets before and after each Visual Studio solution or project is built.
Build management –Allows you to stop and delete builds from within Visual Studio.
Build configuration –Simplifies the ability to specify what tests get run as part of a build.
Build project file location flexibility –Provides the ability to store the MSBuild project file (and its associated rsp file) anywhere in the version control hierarchy instead of forcing the use of the TeamBuildTypes folder.
Support for GUI tests – Allows running graphical user interface (GUI) tests as part of the build.
Check-in Policy – Supports a new check-in policy, which prevents users from checking-in code when a Continuous Integration build is broken.
Managing build server – Improves ability to manage multiple build machines.
Workspace mapping – Build definition can be associated with a "real" workspace, meaning code from multiple team projects can be retrieved, client mappings can be specified, etc. Working folder mappings will be managed in the GUI instead of in workspacemapping.xml

No comments: