No announcement yet.

Critique my strategy for multiple environments (DEV, QA, PROD, etc)

  • Filter
  • Time
  • Show
Clear All
new posts

  • Critique my strategy for multiple environments (DEV, QA, PROD, etc)

    Hi All,

    My company has been using SVN for a number of years but due to the structure of our repository we have run into issues in the past with things like code going in to prod from a project that hadn't been approved, qa config files going into prod, etc.

    We have eliminated the config file issue by externalizing the server specific configurations and housing them on the server (stored in SVN separate from the apps because they really shouldn't be part of an app deployment anyway). We still periodically have an issue with untested/unapproved code moved to the "next" region.

    Any changes we do are associated with what we call a work order, essentially a ticket. That work order can be a bug or part of a new project. I have come up with an SVN structure that probably diverges from the norm but I feel represents our working environment.

    We have a single repository with a PROD folder, a STAGING folder, a QA folder, a DEV folder and a WORK_ORDERS folder. Inside of these folders are our applications. Prod is always our baseline.

    When a work order comes down, the developer will create a work order folder under the WORK_ORDERS folder (i.e. wo5000) then inside that folder he takes a branch of the application needing a change from PROD. The developer then makes any changes necessary and after testing locally, merges the changes into the DEV application and deploys it to the dev server. This goes on until the code is ready to move to QA. The developer then merges the WORK_ORDERs code into the QA application and deploys to QA. Once approval has been granted to move to prod, the developer merges all the changes in the WORK_ORDERS folder into STAGING. This code is then built and will move to production (we have an intermediate "final" check called preprod; this code goes in preprod and prod). Our change management team then does their verifications and merges the code from STAGING to PROD.

    I feel this gives us the flexibility to have multiple "units of work" going through the regions without one change stepping on another's toes and without accidentally moving a change in that isn't ready to move. I'd like some critiques though as I've had some pushback from the developers saying it's too much work (these are mostly Visual Source Safe users, the java guys haven't complained too much). I want to find the correct balance between flexibility and ease of use. If there are better ways to do things I'm all ears.


  • #2
    There is no "right" way to use Subversion. Here, we promote builds of the software through the dev/staging/production lifecycle in a bespoke system outside of Subversion. Whatever works for you