a few days ago Brian Harry made public the news where commented that we can already count with a Team Build Server in our service of Team Foundation Service. Put another way, this means that we have at our disposal a Team Build Server in TFS on the cloud. Just great! (Friend Vincenc has also written a post about it)
This has many great advantages, but we also have to take into account several things to work with this model.
Important: We do not have access to the physical machine from Team Build
This means that we cannot change anything in it so that our projects compile, run unit tests, etc. in this server. I personally think that this is great, a software project should be able to be compiled and packaged only from the contents in the Source Control repository.
If you use COM components, or work with an environment of compilation that requires you to install something in it to be able to compile, because you’ll have to revise your model of development to use Team Build in Team Foundation Service.
Initially the Team Build single VM will be installed
-Visual Studio 2010 SP1
- Visual Studio 11 Beta
Java for now nothing at all… Although clear, it will be in the final package, as ECLIPSE with Maven 2 and Maven 3 customers need.
I have done the test of the "Hello World" for Team Build in 10 minutes and works great, although if instead of MSTests use XUnit or NUnit, because you have to devote a few minutes to Setup.
Finally, an interesting detail. When we define the output of our Build directory, usually usually you do in a share formatted\\SERVER\SHARE\BUILD.
In this case, we also have that option, although I do not think that anyone open this door to the world. The best seems to be that if we configure the output of the Build directly in Source Control, we buy cholón space in SC, but well… for that is.
What happens with my custom build templates?
As the Build Controller and Build Agent concept remains the same, because it isn’t to change us much the way in which we work if we have customized our Build templates. Simply access the configuration of the Build Controllers and already we can continue working as before.
There is trap a?
Yes, although in reality it is not trap. For example, you can make a template of Build to mount a specific environment to build a solution (e.g. registering COM components, prior to the compilation). But of course, as the AZURE VMs "have no State", because you will lose these changes when you refreshed them.
Although as the build runs where we need it, because we can return to this state when we need it…
This point remains to be seen because I understand that it will be an environment more like a Sandbox to which we have access from the final version.
Now to migrate a couple of templates custom Avanade Spain to TFS AZURE, forgiveness to Team Foundation Service and prepare the next post.
Saludos @ La Finca