For all of the developers and DevOps people out there, Visual Studio 2015 was released this week. I’ve been working with it for a week on the latest build of Win10 (WinX, build 10240), and I must say, I’m impressed. One of the MOST impressive things has been the ‘backwards compatibility’. My company uses Visual Studio 2013, and I was able to open my project in 2015 with no issues and then go back to 2013 with no problems, either. If I start using some of the new VB.NET features, I might have some issues, but I think I’ll be able to get everyone to switch to 2015 pretty quickly 🙂
Several important things have changed with TFS 2015 / Visual Studio Online build process.
One of the first things that I found in the changes to TFS is that there is a new option about what to do with the artifacts of the build (the source / deployable items). Previously, these would just go into some shared drop folder. It looks like now, these artifacts can be pushed back to the source control server. That makes the need for a shared drop location unnecessary. Also, it allows the artifacts to be downloaded directly from the internal or hosted TFS website. This is both a good and bad thing, as it’s great for not needing to have a shared location anymore for drops, but it does add time to the build to upload it to the server. Plus, that also means that, if you use VSO, your files are going up to Microsoft. Fortunately, sending to the build server is only an option, and the old style of dropping the files in a share is still around.
One more thing that I did want to point out is that Team Foundation Server and Visual Studio Online’s build engine has been updated AGAIN. When I first saw the change, I was like ‘WTF… in 4 version (2010, 2012, 2013, and 2015), they’ve completely redone the build system 3 times!?!’ I think the XML build process, al-la Ant was a pain in the rear. The move to XAML looked to be going in the right direction, but the build scripts were very complicated. When I saw the ‘new’ build system, my first thought was… ugh, really? Not interested.
Then I took a better look, and tried it…
After playing with it for a bit, I like the way that the new build engine incorporates the visual style of the XAML builds and the succinct style of the XML builds. There is a nice visual aspect to the builds, but there is enough customization that a good balance has been reached. Plus, it is very easy to extend the new system.
There are a couple of concepts to be aware of when using the new system. The old build system had some options turned on by default that would generate the structures correctly in the build. Those options are not on by default in the new system. The following article helped me with part of the configuration: http://www.deliveron.com/blog/building-websites-team-foundation-build-2015/ The import part of of the article is what the settings are for the MSBuild arguments:
/p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
That coupled with the setting that I found for keeping the structure https://dscheidt.wordpress.com/2014/06/01/solving-a-problem-with-tfs-and-building-regular-applications-using-tfsbuild/
Using that together in the MSBuild settings will build the projects in the same structure that the directory is in.
One last thing that has changed with the build system… If the new build system is used, the TFS build agent doesn’t need to be installed through the big setup.exe that prior to 2015 was needed. Now, on the web site, there is a link to download the agent by itself. After that, one just has to run the Powershell script to configure the agent.
All-in-all, Visual Studio and Team Foundation 2015 look like an excellent release!