views:

76

answers:

2

SOX requires that we have a separate group deploy our ASP.NET web to production.

Currently, that group has access to our current code repository in VSS and uses VSS to deploy code that has been checked into VSS.

How are deployments typically done for web applications?

As a developer, I have used the Deploy function in Visual Studio to deploy code to a network share which corresponds to a IS virtual folder, but I don't think we can expect that the deployment group will be purchasing a copy of Visual Studio just to do deployments.

We could check the code into TFS, but what is the minimum software that that group would need to perform the deployment? Would a Team Explorer Client Access suffice?

I am aware that Team System has functionality to automate the building of an application. Do people typically deploy to Production by copying aspx and dlls files from the QA environment to production or do you normally deploy from TFS or even VS directly? It seems to me that the preferred approach would be to deploy from the QA environment, since that is the environment that must have been approved for release or that those files should be checked into TFS and the deployed from TFS, assuming you can deploy from TFS.

What confuses me is whether bin (binary) files that are local to the project-do they go into TFS? Is so, doesn't this create problems for other developers in that only 1 developers-the one with the binary checked - can actually debug because debugging requires write access to the binaries? Does this mean that the binaries shouldn't be checked into TFS? But eventually, if you deploy from TFS, the binaries HAVE to be added to TFS. Are they added as a separate (compiled) application node? If so,m this sounds real ugly. I would assume not. How does one ensure that the binaries match the source code that we mark with a particular version number?

Obviously, I'm clueless. Can someone give me a general idea of how you handle version control and deployments in particular using TFS?

A: 

One minimal possibility (i.e. relatively simple and using free software) is using Powershell scripts to compile using MSBuild. To work with your source control, you can use Subversion, which can also be scripted.

I would suggest you do some research into Continuous Integration scenarios to learn more about what you're asking about.

Jaxidian
A: 

Sounds like you're asking what are best practices for using TFS for deployments. This book from the TFS team should answer most of your questions. The big mindset difference between TFS & VSS is, by default, TFS checkouts do not "lock" a file from being edited by another developer. TFS has a pretty decent merge capability to handle changes to the same file. The TFS books explains this in much more detail and why it is a good thing.

As to the handling of your application binaries, they should normally be generated by the build process and automatically deployed to the target environment (dev, qa, staging). Third-party binaries that your code depends on would be checked-in along with your source code to ensure the build process has all the required assemblies.

As you mentioned, deployments to production should be manually triggered from a qa or staging environment not accessible to developers to comply with SOX rules.

Jaxidian makes a good point about researching Continuous Integration. TFS supports triggering builds on check-in which makes CI possible.

Sixto Saez