wiki:CodeManagementReleaseProcessOld

Version 1 (modified by jim, 6 years ago) (diff)

Created page

JK: This page is not finished... Will tidy & complete ASAP

Code Management and Release Process

The code for the site, including all Drupal core, contrib and custom files (but excluding settings and uploaded assets) is stored in an SVN repository available at https://tech.transitionnetwork.org/svn/.

Overview & Principles

  1. Developers work on their own machines and check into the DEV branch of the SVN repository (https://tech.transitionnetwork.org/svn/branches/DEV) ONLY when their code TESTED functional
  2. The development server (DEV) mirrors the LIVE environment must be used to test this code before moving to LIVE.
  3. There is a TEST server which can also be used as required, but is optional unless there is a lot of development work going on or many developers need to test their work in preparation for a release to LIVE.
  4. The LIVE server ONLY EVER gets tagged releases put on it. Such releases must be tested (both on a local developer machine AND on DEV) prior to release. Hence, the LIVE server moves from one tagged release to the next.
  5. Database backups must happen before each release to LIVE - this way each release on LIVE has an associated database backup.

Release Process Detail

The process is as follows:

  1. Developer(s) commits their changes to the DEV branch (presently https://svn.webarch.net/transition/code/branches/DEV but recommend simplifying this). Testing is done on DEV server to ensure things work as planned.
  2. OPTIONAL: Developer updates the TEST server using same code.
  3. OPTIONAL: Developer solicits feedback and testing from managers/stakeholders if complex changes or new development. This is probably on DEV, but could be on TEST.
  4. Once happy, developer tags the code as appropriate (e.g. v1.3.1 "The crown jewels" etc) as a new copy in the LIVE branch. The source of this should be the DEV branch, since TEST server should only test tagged and ready releases before they make it to LIVE.
  5. OPTIONAL: points 1-5 happen as many times as required to get the release ready, tested and signed off.
  6. Developer backs up and updates LIVE using the latest tagged release. NOT USING MERGE!!! Using 'svn switch' in our case. If there is a problem the developer can always switch back to the previous tagged release for LIVE and examine the issue in TEST.