Personal tools
You are here: Home Blog Enterprise Subversion Methodologies
Document Actions

Enterprise Subversion Methodologies

by Nathan Cassano last modified 2007-10-29 13:09

How to setup subversion data flow for high concurrency.

Disclaimer: This is a work in progress.


Enterprise Scenario

I was working with a large corporate code base with multiple products being worked on by multiple developers and multiple QA persons all sharing the same code base. The possibility for conflicts and synchronization issues were amble.

Repository layout

The repositories are laid out according to each major project. Each project will contain three main directories which are dev, qa and prod. The dev folder contains three other folders which are trunk, tasks and tags. The dev/trunk is the current stable copy of the project. The dev/tasks folder contains the development branches of the trunk. The dev/tags folder is for developer milestones of their development branches. The qa folder contains two folders which are tasks and releases. The qa/tasks folder contains the tagged releases of developer tasks. The qa/releases folder contains the release candidates put out by development. Finally the prod directory has a single directory called releases which contains all the production releases.

Workflow

Here is an outline of the workflow of product lifecycle.

Development for a given task begins by branching the current project. Once development is finished and ready for QA to test their code changes a tag of the task is created for QA. They then test the tag for quality control and bugs. If the code is found to be unsatisfactory it is reported back to development and they being another development cycle. Once the code has been approved by QA it will be included in the scheduled release candidate. At the time for a release candidate development creates a release tag of all the approved tasks in a merged release candidate and it is given over to QA for a round of integration testing. If the integration testing fails development will make the appropriate changes and put out another release candidate. Once a release candidate has been approved by QA they will then make a production release from the candidate. Finally QA can deploy the production release to the production environment.

Security

Development:
  • Modify the project trunk
  • Create/Modify project task branches
  • Create task QA releases
  • Create QA release candidates
Quality Assurance:
  • Create production releases
Administrator:
  • Create new projects
  • All access
« May 2012 »
Su Mo Tu We Th Fr Sa
12345
6789101112
13141516171819
20212223242526
2728293031
 

Powered by Plone CMS, the Open Source Content Management System