Subversion planning for development, staging, live

Question

Good evening everyone.

I am in the planning stages of restructuring our subversion process and deployment in the attempt to minimize code loss and production deployment issues. Our current system simply consists of creating a sub domain name on a random server to test with before pushing live which drives me nuts.

I wanted to hear some suggestions or opinions on my current plan and get feedback or ideas on how to make this system better.

The Details:

• Small development team.
• Dev and staging exist on the same machine.
• Production versions exist on other servers.
• Roughly 30 projects are web related (websites, web applications, web services).
• Roughly 30 projects are desktop applications, DLL’s, components, bat files, etc.
• Dev sub domain names accessible via VPN access only.
• Staging sub-domains for web are publically accessible. exe staging is only accessible by VPN.
• Each project will have a dev and staging sub domain and repository. Dev version is a branch of the staging trunk.
• Primary dev repository: dev.domain.com (generic names used for example).
• Primary staging repository: staging.domain.com (generic names used for example).

Deployment:

Development versions of projects are branches of the staging trunks. Staging holds the repository for the specific projects. Files are then manually copied to production location or deployment scripts are executed.

Example: Developer uses local copy obtained from projectname.projecttype.dev.domain.com (site1.web.dev.domain.com). Changes are made to local version and are merged to the project dev branch for testing. After all testing is complete the branch is then merged into the project trunk. If the project trunk passes all tests the project is pushed live.

Subversion repository structure: *note: File structure will match the structure of domain names. *

Development branch: Checkouts always occur on this server to local development environment.

             dev.domain.com 
         web.dev.domain.com 
   site1.web.dev.domain.com
   site2.web.dev.domain.com

         exe.dev.domain.com
    app1.exe.dev.domain.com
    app2.exe.dev.domain.com

Staging trunk: Never touched by developers. Files are updated only by merging the branch into the trunk for the specific project. Test installs before pushing live. Should be assumed as production capable but not customer accessible.

             staging.domain.com
         web.staging.domain.com
   site1.web.staging.domain.com
   site2.web.staging.domain.com

         exe.staging.domain.com
    app1.exe.staging.domain.com
    app2.exe.staging.domain.com

How does this look? Is there any functionality I am missing or going to lose? Is their a better system I should be using?

Thanks in advance everyone!

Answer 1

It looks good. Basicly you have "feature branches" for developing stuff isolated from each of the release branches (trunks) for which you have a "hands off" policy in place so they should have release quality during 90% of the time. You could add tags for your releases so you know exactly what has been released (and what would have to get rolled back of things go very wrong).

Keep your project isolation as long the overhead stays managable.

thumbs up.