4
votes

I'm fairly new to Subversion. Most of my work so far has been with Visual Source Safe. I'm looking to improve my deployment process with SVN and TeamCity. This is my plan:

There would be three branches:

  1. Development (/trunk) - Entire ASP.NET solution, including a Web Deployment Project.
  2. Staging (/branches/staging) - Web Deployment Project output (files needed for execution only - bin, .aspx, images, etc)
  3. Deployment (/branches/deployment) - same as Staging

The CI process:

  1. Commit source changes in trunk.
  2. TeamCity detects the change, builds the solution and runs unit tests.
  3. If all tests pass, TeamCity commits Web Deployment Project output to branches/staging and exports it to wwwroot on the staging web server.

Then when I'm ready to deploy to production, I'll do the following manually:

  1. Merge branches/staging with branches/production
  2. Update production web server's working copy of branches/production.

Does this make sense? Is there anything that a VSS user like myself might be missing/misunderstanding in this process?

3
This is the process I'm still using today - stackoverflow.com/a/3098613/26226jrummell

3 Answers

4
votes

I've written a pretty long post on how to do this with ASP.Net and web deployment projects - sounds right up your alley (don't know if I'm allowed to post this - mods?):

http://www.diaryofaninja.com/blog/2010/05/09/automated-site-deployments-with-teamcity-deployment-projects-amp-svn

4
votes

Late answer, but can be helpful to the readers of this thread:

I have done a little online research and found a step-by-step tutorial that may help with your problem.

This tutorial covers the basics of the continuous integration (CI) and the means to build a new database whenever a new change is detected on the source control repository, run specified unit tests against the database, and synchronize tested database to QA environment.

The necessary prerequisite to implement the continuous integration (CI) in your database development process is to have a database under source control.

2
votes

This might work for you, but usually the stage is the place where customers accept changes. If you deploy on each build they dont get a consistent behaviour.

We dont keep the build result in SVN. For us it was ok to just have it in Teamcity under artifacts. I am not shure if we use best practice at this point.

You will be so much happier with SVN and Teamcity...good luck!