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
Related
I'd like to start exploring options outside of msbuild for scripting my builds, like CAKE or FAKE.
What's the best practice for developing .NET Core in Visual Studio but using external build scripts? Like, how does this actually work in practice?
I'd like to continue to take full advantage of the VS environment, including Intellisense, package management, IDE features like Go To Definition, etc.
Do people somehow customize/override the VS F5 and/or Ctrl-Shift-B behaviors? Or do they use .csproj files and let VS and msbuild do its own thing until it's time to generate a "real" build, and then run their own scripts at that time?
Locally on your development machine you usually run build scripts from command line. You don't write build script to help you while developing. You write them that your code is verified by an automated build and that you automate processes like creating deployment packages, publishing nuget packages...
Most common practice is contionous integration approach. This means that when you or someone in your team commits/pushes code to the version control system(like git svn...) your selected continuous integration tool (like jenkins, team city...) pulls source code from version control system and runs your build script which for example compiles your code, run tests, creates deployment package.
I would also suggest that you take a look at flubu. Flubu is a cross platform build automation tool for building projects and executing deployment scripts using C# code. It's easy to learn beacuse you write your build script entirely in c#.
More about flubu can be readed here: https://stackoverflow.com/a/46776658/3118784
We have a C# .NET project using Visual Studio 2013 and we're setting it up to release and deploy with Visual Studio Team Services (VSTS). The websites were pretty simple and easy to set up and they work fine. A few projects are libraries or Console applications and we're trying to determine the best method for creating an automated release for these.
The publish profile asks for a location to publish to - we've experimented with the build drop on our VSTS build server (where all of the other files are) and then asks for a website, a UNC path or a CDROM. We chose "UNC Path" and put the same build drop location in, but in UNC format.
It hasn't really worked yet, so I thought I would see if any best practices for creating VSTS releases and deploys for Console or Code Libraries exist.
Thank you!
Have you considered installing the agent on the target environments and using a release definition that simply copies the right files at the right place?
Regards
Note: copy path shouldn't be hardcoded and rely on variables.
To specify the agent queue by going to the tasks tab when editing the release definition. Click on the "run on agent" header, that will open the details, select your queue here.
Agent queues can contain multiple agents, so your job when you add agents is to organize them by queues that make sense in your context.
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.
We are currently evaluating different applications that interface with Visual Studio 2008 (C#) and Subversion to do automated builds of our core libraries. We are hoping to have nightly builds performed and either email the list of changes made to each developer or have the latest versions be pushed to each workstation. What has been your experience with these tools and what are some recommendations?
Suggested software
Cruise Control .NET
Hudson
TeamCity
Suggested articles
Continuous Integration: From Theory to Practice 2nd Edition (CC.net)
Automating Your ASP.NET Build and Deploy Process with Hudson
Cruise Control.net (ccnet) does everything you are looking for. Its pretty easy to use, just make sure if you are going to run it as a service, you give it an account and don't make it run as network service, that way you can give it rights on intranet boxes and have it do xcopy deploys.
It has all kinds of email modes, on failure, on all, on fix after failure, and many many more.
Hudson is the easiest continuous-integration / daily-build tool I've seen. Not sure if it meets all your requirements.
Take a look at the JetBrain's (guys behind ReSharper) TeamCity
I've used cc.net with nant and msbuild with great success, would highly recommend it.
At my last employer I set up a buildserver with cc.net. Expect at least one or two days work to set it up. I used cc.net together with nant and msbuild. These projects have a lot of overlap in functionality so it might be a good idea to think about how you want to set everything up.
The setup I eventually settled with was cc.net on the server to retrieve the project from subversion and fire off the nant scripts. nant was used to call msbuild to build the visual studio .sln files and do all the other build steps like running tests etc.
I had a quick look at teamcity too. On first sight it looks a lot better than cc.net but I didn't have time to try it out yet. It's certainly worth checking out.
I use CC.Net along with SubVersion and MSBuild to accomplish this. Here is a great guide for implementing this which I followed on found very helpful.
A couple of tidbits about working with cc.net and msbuild. If you are building C/C+= projects, msbuild is, um, unreliable at least with VS 2005 (and perhaps earlier). I have not tested with VS 2008. We found that sometimes msbuild would work properly, sometimes not. In trying to solve the problem, we found vcbuild.exe which seems to work well in place of msbuild when building C/C++ solutions.
If you are using trac for issue tracking, the bitten plug-in works well. It's not platform specific (we run it on both Windows and Linux at work, with msbuild/mstest and make/gcc/cpptest respectively).
I am using hudsons Jenkins for getting daily build. It really very easy to setup and maintain. And it have a lot of plugins which full fill our requirements.
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.