Release Management

Repositories / branches:

1. trunk
   • reference repository
   • everything that goes into production has to go here first
   • 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.
   • functional stuff, which will not (or not yet) be implemented for the BeWelcome website, are preserved in such branches
3. labs (not available yet, please say so if you would like to have it)
   • development repository
   • place to share and evaluate (accessible through www in contrast to private/feature branches)
   • 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) is limited to NDA bound volunteers
5. production
   • stable, released code
   • copy of the latest tested and tagged version of alpha
   • high priority fixes (security relevant) can be introduce her and introduced into trunk/alpha afterwards
   • this version is accessible through www.bewelcome.org
6. old
   • old version of production
   • kept for easy reference/recovery of previous version
   • 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
      • optional stuff:
        • create and use a temporary branch for bigger changes
   4. commit / merge to trunk at any time you feel like
   5. if you would like to get feedback set the follow up in trac to code review or test on test
   6. once stable or bug fixed, set the follow up to move to alpha and add the corresponding revision# as a comment
2. alpha merge:
   1. The revision is checked by an alpha developer according to the Alpha Merging Guidelines
   2. If they fail the follow up is set to test on test again and the developer informed
   3. If everything is fine the revision is merged to alpha. If the database can not updated automatically a database manager will take care of this manually upon request. (Alpha Merging Guidelines)
   4. The ticket status is set to alpha
3. alpha testing:
   1. The changes and all potential cross effects are tested on alpha according to the Alpha Merging Guidelines.
   2. If approved the ticket is closed and follow up is set to release
4. release:
   1. An alpha developer releases the approved changeset or full alpha branch version to the production site by a script assisted system:
      • she commits / merges the code from alpha to production
      • * a hook script copies the code from production to the directory running www.bewelcome.org. and moves the previous code to old.bewelcome.org
      • in case of problems with the new version, the release is reverted
5. emergency bugfix
   • In case an emergency bugfix is needed on production the normal release chain can be bypassed
     1. the fix is committed to production by an alpha developer
     2. a hook script copies the code from production to the directory running www.bewelcome.org.
     3. the fix is introduced into trunk and passes the normal release chain to make sure it is present in all future releases as well.

• all steps are visible to the public through the svn-commit mailing list and ticket system.
• Everybody can intervene at any time if he recognizes something potentially harmful going on.

Persons involved

• SVN Developer: everybody with SVN commit access to trunk. Granted to everybody upon request, revoked after 3 months without commit and after abusing the system.
• NDA bound Developer: everybody who signed a legally binding Non Disclosure Agreement (in preparation) to protect member data and actively contributed for at lease one month. Revoked after 3 months of inactivity and after abusing the system upon decision of the coordinator.
• NDA bound Tester: everybody who signed a legally binding Non Disclosure Agreement (in preparation). Revoked after 3 months of inactivity or after abusing the system.
• NDA bound Database Manager: Only few selected people as needed. Currently Jean-Yves, hkroger, steinwinde.

Assumptions:

• The community asks for frequent updates
• The developers ask for quick deployment of their improvements
• The bewelcome.org website must run stable
• The member data 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
• We can not rely solely on the personal judgment of a few if a developer is trustworthy to handle sensitive data
  • --> we require those developers to sign a legally binding NDA
• We should not spend a lot of time on judging the skills of a developer and restricting his access appropriately:
  • --> people get wide access but are asked to keep there actions restricted to stuff they can cope with and ask more advanced developers to guide them through the first steps when they start to work in a new area.

NDA

An appropriate NDA is currently being discussed among the BeVolunteer? legal team. Until it is available this access level is granted by unanimous decision of hkroger, jeanyves and philipp.