Click here to Skip to main content
15,445,331 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more: , +
I work in a team that heavy supports full deployment procedures for .NET application maintenance projects. That means taking everything from TFS, build it and dump it on the Web server. It also requires overloading TFS with keeping every file from website including images, third party dlls, temp files that are not part of source code because that may risk overwriting or deletion during next deployment. It is causing issues like larger downtime, testing, full backups, full rollbacks, configuration issues, unexpected errors. As the project includes 250+ folders, 1400+ files and 80+ DLLs. Every time deployment made, it changes Modification dates on each file and it becomes impossible to validate which file/configuration change caused the problem if it happens and then we have to do full rollback. All our fixes/changes are limited to max 1-2 files or DLLs weekly. I feel Incremental deployment works better in our case, that means compare/validate and replace only the files supposed to be replaced. It also reduce chance of breaking somethings else that was not part of the change release. The only drawback I see that it may lead to differences between TFS and the Server. But the risk can be reduced by monthly file comparisons/audit through tools to check discrepancy if something not checked into TFS that supposed too, which we need to perform activity even with Full deployment procedures.

Please suggest the best possible deployment strategy for our maintenance projects.

What I have tried:

I recommended Incremental deployment procedure to reduce the deployment issues and testing efforts.
Updated 13-Feb-19 22:04pm

1 solution

Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900