wiki:ReleaseManagement

Version 15 (modified by philipp, 10 years ago) (diff)

--

Release Management - Draft

This document outlines a new way to deploy new versions of BW Rox to the BW website in a reliable way.

Assumptions:

  • The community asks for frequent updates
  • The developers ask for quick deployment of their improvements
  • The bewelcome.org website must run stable
  • The memberdata must be kept safe (everybody with potential access has to sign a legally binding NDA)
  • As a volunteer project we can not rely on single persons
  • Small improvements must not be delayed by big reconstruction work

Repositories / branches:

  1. trunk
    • reference repository
    • only code that works on the local environment is accepted
    • testing, code that seems to be broken has to be removed immediately
    • this version is accessible through test.bewelcome.org
  2. private / feature branches
    • everybody can create/delete temporary branches for easy development. These branches can be partial or complete branches.
  3. labs
    • development repository
    • place to share and evaluate
    • all code can go here, is regularly refreshed from trunk
    • this version is accessible through labs.bewelcome.org
  4. alpha
    • stable, pre release code
    • this version is accessible through alpha.bewelcome.org
    • the access (through svn and http) is limited to NDA bound volunteers
  5. production

Workflow:

  1. development:
    1. check out recent code from trunk
    2. create a ticket or assign an existing one to yourself
    3. develop on your local machine
      • optional stuff:
        • create and use a temporary branch for bigger changes
        • commit to labs to show others what you are working on / get feedback
    4. commit / merge to trunk
    5. once stable of bug fixed, set the ticket state to quality assurance and add the corresponding revision# as a comment
  2. quality assurance / alpha merge:
    1. The revision is reviewed by a NDA Developer? according to the Quality Assurance Guidlines
    2. If they fail the ticket status is set to active again and the developer informed
    3. If everything is fine the revision is merged to alpha. This includes update of the production database if needed. (Alpha Merging Guidelines)
    4. The ticket status is set to alpha
  3. alpha testing:
    1. Alpha is checked by at least two NDA Developers? or NDA Testers? according to the Alpha Testing Guidlines?
    2. If approved (if possible about twice a month) the status of the corresponding Release Ticket? is set to approved (maybe an automated tagging of this version in alpha branch could happen)
  4. release:
    1. A Release Manager? moves the approved (tagged) version to the production site
    2. The Release Ticket? and all tickets that correspond to the release are closed.

Persons involved

  • SVN Developer: everybody with SVN commit access to trunk. Revoked after 3 months without commit.
  • NDA Developer: everybody who signed a legally binding Non Disclosure Agreement (in preparation) to protect member data.
  • Release Manager: NDA bound Developers who ...(To be defined) . Currently JY,Steinwinde,Lupochen

Attachments (1)

Download all attachments as: .zip