wiki:ReleaseManagement

Version 9 (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 memerdata must be kept safe
  • 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. 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
  3. alpha
    • stable, pre release code
    • this version is accessible through alpha.bewelcome.org
  4. production
    • stable, released code
    • this version is accessible through www.bewelcome.org

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
    4. commit to labs to show others what you are working on / get feedback
    5. once you consider it to be stable, commit it to trunk
    6. set the ticket state to quality assurance and add the corresponding revision# as a comment
  2. quality assurance:
    1. The changes are reviewed by one Release Manager? or two SVN Developers? according to the Quality Assurance Guidlines
    2. If they fail the changes are reverted and the developer informed
    3. If they are approved the ticket status is set to approved
  3. alpha merge:
    1. The revisions are merged to alpha by a Release Manager? as soon as possible. This includes update of the production database if needed.
    2. The ticket status is set to alpha
  4. alpha testing:
    1. Alpha is checked by at least two SVN Developers? or Alpha 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)
  5. 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.
  • Release Manager: everybody with SVN access to alpha. Currently JY,Steinwinde,Lupochen

Attachments (1)

Download all attachments as: .zip