Say I have a c# web application project in a TFS Team Solution that I am deploying to a development server (IIS7). I want to be able to promote only certain code changes to a test server, and then later promote ONLY those changes to the production server.
So for example changes to a web user control and a javascript file should be promoted, but a change to a web form should not be promoted.
Using the deployment feature in Visual Studio seems to be an all-or-nothing proposition.
Short of manually selecting files to copy/paste, or write some kind of app that compares files in a target and source directory, list files that are different, and lets you select source files to promote, what do teams usually do in this situation?
In short: how can I reliably promote select files/code from environment to environment without also including other changes that should not be promoted?
Create two branches in TFS, one for development and one for production.
Merge dev->production only changes that you need.
Create deployment packages from production branch.
Related
Due to some (insane) limitation at my customer, I built up a WCF layer using Azure, just as a proof of concept. Now, what is a smooth way to re-deploy it to their on-premises server? Is there such a way?
I understand that the publishing of my service to the cloud is a nice luxury that can't be performed as easily when deploying on-premises. :(
Because of some (equivalently insane) limitations, I'm not able to connect my computer (with the IDE and source code) to the internal net of the customer. I might be able to get an IDE installed on their computer, though. Is moving the source code files and recompiling the only option?
In a perfect world, I'd like to copy the entire project to the customer's computer and just change some settings in a deployment file (or whatever thing stores that information). Is it possible?
Well, what about the deploying the solution to the local temp folder by using the Deploy Wizard from Visual Studio and then simply create by hands a new application on server side and copy all files there.
I want to create an application that will automate a very specific build process that is repeated daily.
I need to build a C# web app, package the dlls and other necessary files (diff from last checkin in svn) into a .zip file in a certain structure.
Connect to a secure remote Windows web server (with specific authentication), copy, unzip and deploy the files to the correct locations.
I was thinking a C# console app which will handle the connection to the remote server, and a combination of file operations in the code, or batch files run on the local machine and the remote server. I intend to use batch script to build the Visual Studio project, and run a diff on the svn tree and export changed files to a certain directory structure.
Is this at all possible? How would I achieve the remote connection and copy the files?
Just wanting to see your thoughts.
Thanks for any help.
What you're trying to create is effectively build automation for which there are some excellent continuous integration products available. My advice would be to jump on the free, Professional version of TeamCity and use this to orchestrate your builds. It plays great with SVN and has built-in Visual Studio and MSBuild runners.
While you're there, unless you're trying to do something very bespoke, take a look at using Web Deploy to push the app out. There's a five part blog series titled You're deploying it wrong! which walks you through the entire process.
I have an asp.net application that I currently deploy to 4 different environments on the client's servers. At the moment we deploy by copying over individual assemblies and content files but the whole process is time consuming and error prone. Basically I'd like a method of preparing the application for deployment that will give me a folder containing the application (no source code etc). No IIS changes are required. It would be good if I could specify different webconfigs for different environments.
I've looked at msbuild, msdeploy, etc and I'm not even sure which is the right tool for the job. I'm tempted to go with a batch file that copies only certain file extensions but I'm sure there must be a better way of doing this. Any help please?
Take a look at the Visual Studio Publish Web Site feature.
I have a small .NET WinForms application, and couple of linux servers, DEV and CL1,CL2..CLN (DEV is development server and CL* are servers which belons to our clients, they are in private networks and it's a kind of production servers)
I want an update mechanism so that
(1) i develop a new version and publish it to a DEV
(2) users of DEV-server install latest version from DEV
(3) users of CL2 (employees of client2) install stable version from CL-2 directly
(4) application checks for updates using server it was installed from (so, if it was installed from CL-2, it should check CL-2 for updates)
(5) i should be able to propogate the update to a selected CL-server (using just file copy & maybe sed; not republishing), if i want that (and if i don't, that CL-server will have an old version until manually i update it)
I tried to use clickonce, but looks like it meets only first two requirements.
What should i do?
ClickOnce should handle 1-4 to be honest. All that would be needed is that for each site you want to deploy/update from, you'll need it to have its own publish, which after looking at your specifications is not incorrect to do.
What you could then do in order to make 5. applicable, is create an automated process to re-publish the file. This could perform a publish and then upload to the correct server.
Remember that ClickOnce needs a new manifest per version, and a new version requires a publish, so I'm not sure that you'll get around 5. with a simple file replacement.
Kyle is right. But for the 5th note, you just need to copy the deployment, and then use mage to modify the installation URL and point it to the new server, and then re-sign the manifests.
I support an app that we deploy to a DEV, QA, PROD servers. The way I handled this is that
I created created a cmd file that has command line calls to MSBUILD. It builds the app once for each server with the appropriate URLs and switches. I give my DEV and QA builds a different AssemblyName that way I can run all 3 environments side by side. This way my build process is automated and I don't have to publish at all.
Here's an article that describes the parameters you can use.
http://msdn2.microsoft.com/en-us/library/ms165431(VS.80).aspx
#Kyle,
For the above solution can the different versions run side by side or do you get errors indicating the app is already installed.
What is the best strategy for making changes to a specific file within a C# .NET project and a DEV server and then moving that file to a different environment, say server B? I noticed it always wants me to recompile on the destination server and I figured I was doing something wrong because I didn't think I would have to (plus the server isn't in-house so it is really slow and time consuming).
Any suggestions or strategies you or your company uses would be appreciated.
Make sure you are using a Web Application project where it compiles a DLL, not web site which uses loose code files.
You could use a source code versioning system like Subversion.
use a source control program for source files (like SubVersion) and Cruise Control for binaries built out of those files...
For web application development my experience has been:
Developers have a development environment on their local machines that is attached to source control
A DEV web server with shares to the projects created allows developers to COPY files to the web application folders manually.
A TEST web server where MSI installations ONLY are used to distribute the changes for UAT
A PROD web server where MSI installations ONLY are used to distribute the UAT approved MSI
The size of projects I am involved with usually makes build scripts overkill, most times a project is being worked on it is built many times for debugging etc.