Is there a good guide on how to do this with these two exact pieces of software? I have found a lot of generalized CI setup guides, but none involving these two exact components.
TFS makes setting up a continuous integration server very simple. You will first need to create a new TFS project. Then you need to configure Visual Studio to use your new project. Finally, you can setup a build for the project within TFS. There is a pretty good blog post about how to do it. The important step is setting the build trigger:
You can set various build triggers, including a continuous schedule. Obviously, you can get much more complex with the build definition. Deployment options, config options, but hopefully this will be enough to get you started.
Related
Developers use the Visual Studio (VS) GUI to develop their solutions and get their projects all building using a solution file (.SLN). The build teams using vNext then have to automate those builds using MSBuild instead of devenv.exe (the Visual Studio executable file). This is a serious and chronic problem because not only is MSBuild incapable of building several project types, but the build order is defined in a completely different, and complex, way.
Some Microsoft advice (https://learn.microsoft.com/en-us/archive/blogs/msbuild/incorrect-solution-build-ordering-when-using-msbuild-exe) is to switch to explicit dependencies in each .*proj file and remove all dependency specifications in the .SLN file. This sounds like a person who has never worked in a relatively powerless build team trying to get development teams to:
do a lot of what they perceive as time-wasting extra work and to
change how they do things
What build teams need is a way to automate whatever VS allows dev teams to build. If VS is given a SLN to build, then a vNext build needs to be able to use that same SLN in the same way. Instead vNext currently only offers MSBuild as the build tool. MSBuild has many more options than devenv, so that would be great, IF it could be made to use the SLN to govern dependencies in the same way as VS, and would be upgraded to build all the same project types.
There have been prospective efforts, referenced by PatrickLu-MSFT at Build project using devenv.exe in TFS 15RC1 Build Server, to enhance a vNext build step to allow devenv to be used instead of MSBuild, but those efforts seem to have been dropped.
Maybe someone has developed a custom vNext build step to build using devenv?
Here is an existing extension you can reference, which provides a build task in your TFS/VSTS instance that will allow you to build your projects using DevEnv.com (Visual Studio):
https://marketplace.visualstudio.com/items?itemName=mmajcica.devenv-build
If you want to automatically use TFS/DevOps build whatever solution files our development teams get working using Visual Studio, you could set CI trigger in build pipeline, when the solution build successfully on local, you can check in/commit the changes, and trigger TFS/DevOps builds.
Our team are looking into implementing Code Analysis as a check in policy in TFS.
We've decided on which rules we want to enforce but won't be applying the policies to TFS for a while as we are currently migrating to TFS 2010.
In the meantime to get used to it and start removing Code Analysis warnings the dev team are going to start manually enabling Code Analysis.
So, is there a way we can publish or automatically enforce a set of rules without having to manually edit the properties for every project in every solution?
For sharing Code Analysis settings between projects in VS 2008, see
http://blogs.msdn.com/b/codeanalysis/archive/2006/11/16/faq-how-do-i-share-managed-code-analysis-rule-settings-over-multiple-projects-david-kean.aspx. (The article was written for VS 2005, but the same approach is appropriate in VS 2008 as well. In VS 2010, use of a shared rule set file is a better approach, although it may be specified using the same imported target mechanism.)
I've just been upgrading an Azure project to Visual Studio 2010 and have been taking advantage of the new XML configuration transformation feature that is built into VS2010 web projects. It seems to work great with Azure web roles. I even managed to get the Azure project service configuration file to do a similar thing by following the instructions here.
However, I can't seem to get configuration transformation working for the lone worker role in my Azure project. I know that VS2010 only has built-in support for config transformation with web roles, but I found a good article describing how to get config transformations working with non-web projects. I've followed the instructions and it works - but only to a point. It successfully spits out the correct .config file (with appropriate transformations) into the worker role project's own bin directory, but it doesn't pick this new .config file up when it's put into the cloud package.
I suspect there's some MSBuild trickery needed to get this to work, but I don't know MSBuild very well, so am appealing to any gurus out there for help and/or samples :)
I have found the best way to do this is to use msbuild. I usually do this with a separate msbuild file outside my solution so I keep the local dev settings separate from the production settings. You can find out more here. I then can run the build to change the settings and upload the project to Azure. I can also run this to change the settings and then run deploy through VS if I need to debug the problem. I also have a target in the msbuild file that then can revert everything back to local. It would be nice to have these things in VS (which I have asked for from the product team). The sample project is on github.
This is also explained in the book we wrote in the Life Cycle chapter.
I'm working in a team environment where each developer works from their local desktop and deploys to a virtual machine that they own on the network. What I'm trying to do is set up the Visual Studio solution so that when they build the solution each projects deployment is handled in the post-build event to that developers virtual machine.
What I'd really like to do is give ownership of those scripts to the individual developer as well so that they own their post build steps and they don't have to be the same for everyone.
A couple of questions:
Is a post build event the place to execute this type of deployment operation? If not what is the best place to do it?
What software, tools, or tutorials/blog posts are available to assist in developing an automatic deployment system that supports these scenarios?
Edit: MSBuild seems to be the way to go in this situation. Anyone use alternative technologies with any success?
Edit: If you are reading this question and wondering how to execute a different set of MSBuild tasks for each developer please see this question; Executing different set of MSBuild tasks for each user?
If you are using Visual Studio 2005 or later, project files are MSBUild files. Inside the MsBuild file, there is an "AfterBuild" target. I would recommend using this to do your deployment tasks, instead of the Post Build Event.
By using MSBuild tasks, you are more prepared to move into a Continuous Integration system like CruiseControl.NET, or Team City.
I'm not sure why all of your developers have their own virtual machines, it would seem at some point you'd want a central location where all developers work is built to ensure the code from all developers will integrate and build (this is a reason for using Continuous Integration systems). I'm sure you can find a way that CruiseControl.Net or Team City or one of several other choices can help you in this scenario. But as far as getting the initial setup, use MSBuild.
i'd look into MSBuild or ANT
I think most people here understand the importance of fully automated builds.
The problem is one of our project is now using an integrated Visual Studio Setup project (vdproj) and has recently been ported to Visual Studio 2008. Unfortunatly, those won't build in MSBuild and calling devenv.exe /build on 2008 just crashes, apparently it does that on all multi core computer (!!!). So now I have the choice to either rollback to .Net 2.0 and 2005 or simply ditch Visual Studio deployement, but first, I'd like a second opinion.
Anyone knows of another automated way to build a .vdproj that will not require us to open the IDE and click on stuff?
WiX was what I had in mind when saying we would ditch vdproj. Do you have any experience with it, good things, caveat?
The low cost solution is to switch to using ClickOnce, which you can automate using MSBuild. But if you still need to create a Windows Installer package, you will need to convert your project to WiX (pretty straight foward) and build that with your solution.
This will get you started:
Automate Releases With MSBuild And Windows Installer XML
I've used WiX a little bit before, and generally I found that it's great once you figure out what to do but there is a steep learning curve. If you spend a solid day going over the WiX tutorial you should be be able to get 80% of your setup working.
WiX Toolset Tutorial
I had the same requirement and ended up using what is suggested in these two links
David Williams Blog
MSDN article
Basically, since Team Build, by itself, will not build the setup projects for you, this approach has you add a new build step after the regular build is complete. This step fires off a second build by launching the devenv.exe. The IDE will build your setup files. The extra build is a bit costly but we only needed it for builds that were going to be pushed out. The Daily build at most would need this customization our CI build does not need to build setup files each time.
After that you execute some Copy commands, once again build steps that show up in your Team System build results, to move the setup files to a network share etc.
It feels a bit like a kluge at first, but it does work, it is also a full-fledged part of the automated build in Team System so it worked for my Continuous Integration goals.