Deployment Suggestions

I'm wondering if anyone can provide any constructive feedback about the current deploy procedure we use where I work:

• We have three copies of the code in seperate Mercurial repositories: Dev, PP (Pre-Production) and Live. Changes are made on Dev, pushed to PP for User Acceptance Testing then pushed to Live once accepted.开发者_如何转开发
• Builds are done using TeamCity to created a precompiled version, changes are not made by hand (everything has to go into source control). The builds are provided as zip archives as artifacts in TeamCity. Class libraries are build on demand and linked into the main build as dependencies, Bin files are only kept in source control where we don't have source code.
• Builds are copied to live enviroments by hand using RemoteDesktop, and unzipped. web.config files are kept from build to build and edited by hand when needed (Live passwords etc. are not kept in source control)

The current things I think are missing are proper Unit- and Integration-testing (ideally using NUnit and something like selenium), but I'd like to see what the community thinks.

---

You could condense this to a single source control instance with TFS and branch your code for release builds.

From there the builds can be autoamted to run, test and deploy to "test" each night / week. Your QA (Quality Assurance) teamwould then test the build (further test on top of the automated tests) and either approve or reject the build.

If the build quality is suitable the QA team can set a build quality through either visual studio or the build notification toolbar app or directly in the tfs portal.

When a build of suitable quality is identified the TFS server can also be configured to do a live push direct from its repository on the marked marked build.

The up side of all this is that the dev team are using the same repository as the QA team and thus are able to feed "tasks" / bug reports directly to them but also the server takes out all that manual deploy stuff in your architecture.

MSBuild also include MStest which in my opinion isn't all that bad for automated testing as it reports (again back to the dev team and) to the project manager information about bugs and tasks, it also comes out of the box agile ready.

the down side ... bit complex and fiddly to setup if your not confident with msbuild, but it's not a massive learning curve if your used to an MS dev enironment.

...

Developers generally have their own "copy" running on their pc of the solution unless the solution is extremely complex in which case a full virtualised dev environment on a separate domain that links to the main domainssource control server may be the way to go.

depends on the solution complexity though.