wiki:SysAdmin/ReleaseProcess

Release Process

Table of Contents

  1. Tagging
  2. Deployment Branches
  3. Upgrade Scripts
    1. Template Upgrade Scripts
    2. Branch Upgrade Scripts
  4. Old Info
    1. Clear Database
    2. Update Language Files
    3. Export Application
    4. Test
    5. Upload to LaunchPad
    6. Update Windows Installers
    7. Update Wiki
    8. Update Demo
  5. See Also

We plan to make release versions of Eden.

This will entail:

  • Creating a QA branch (ideally)
    • features have final integration testing done here before being pushed to the Stable branch
  • Creating a Stable branch
    • deployments should be done from this branch
  • Adding Tags to Releases
  • Building upgrade scripts

Tagging

Tags will be added based on the following schema: 

[BranchName]-[Major].[Minor].[Sub]

The VERSION string will displayu the Tag. If there are commits after the last SubRelease then they also append the number of commits since the last tag + the hash of the commit: 

[BranchName]-[Major].[Minor].[Sub]-#-[Hash]

These commits in between SubReleases should never be visible to users (except maybe on a Dev server)

The Major version number will only change if we:

  • create a new parallel branch which would become the new trunk
  • probably this would be because we change the API in backward-incompatible ways

The Minor release number indicates the normal release.

  • Upgrades between these should be accompanied by some Change Management as users will see some differences (this could be just a mail saying 'some things may change' or could be full User Acceptance Testing)
  • These will often require an update script

The Sub release number indicates a maintenance update to the release. Sub-releases can introduce new features, but they would normally not:

  • replace feature sets
  • remove feature sets
  • fundamentally change the logic/semantics of a feature set

Sub-releases may still require an upgrade script, but usually won't. They normally wouldn't need such stringent user communications or documentation updates.

Git docs on Tags:

Deployment Branches

If a Branch of the code is made to manage releases for a deployment, then there are 2 options:

  • If any significant development is done then it should be based initially off trunk
  • If no development is planned (just backporting any critical bugfixes/minor tweaking) then it can be based off stable right away

Once a Development branch has moved into Production then it should move to being based off Stable once the requisite features have merged into stable (or could even start using vanilla stable releases as deployment branches should converge with that anyway).

Branches based off Stable should have it's version appended to that of the Stable branch, so: 

[BranchName]-[Major].[Minor].[Sub]-[BranchRelease].[Sub]

Branches based off Trunk should have it's version appended to the Major Version of the Trunk branch, so: 

[BranchName]-[Major]-[BranchRelease].[Sub]

If a production site has another Development phase (or is being developed continuously) then a new Development branch should be created for that, again starting from Trunk. This can be deployed to the Dev server and then the test server when ready to move it into Production. Again, after the move to production, then it should move to being based off Stable once the requisite features have merged into stable

Upgrade Scripts

For every update that requires it, an Upgrade script will be added to: 

eden/static/scripts/upgrade/1.a.b-1.a.c.py

The 'pull' script will be modified to call this script automatically

Template Upgrade Scripts

If there are template-specific changes for an update then these will be found in: 

eden/modules/templates/TEMPLATE/upgrade/1.a.b-1.a.c.py

This will be checked for automatically by the 'pull' script

Branch Upgrade Scripts

Typically a Branch will be using a custom Template (even if this is a thin layer on top of other templates).

Branch upgrade scripts will therefore be in: 

eden/modules/templates/TEMPLATE/upgrade/1.a.b_d.e-1.a.b_d.e.py
or
eden/modules/templates/TEMPLATE/upgrade/1.a.b_d.e-1.a.c_d.e.py

This will be checked for automatically by the 'pull' script.

If there is no branch-specific upgrade script yet there is one for the underlying stable upgrade then the pull script should detect this & allow the user to run this instead of nothing or bail & revert.

Old Info

When making a Stable Branch from which to build releases, we need to do these tasks:

Check that all works with a released version of Web2Py

Ensure included files sane:

  • README
  • VERSION
  • INSTALL
  • CHANGELOG

Clear Database

To clear database of test data & reset to defaults:

  • Close Web2Py
  • Delete all files from /databases & /uploads

Clean the files which are created by the deployment-templates of all personal data (i.e. overwrite with version from deployment-templates):

  • cron/crontab
  • models/000_config.py

Update Language Files

python web2py.py -S eden -R applications\eden\static\scripts\tools\languages.py

Merge any updates from ​Pootle

Export Application

This could be scripted: 

cd /home/web2py
# @ToDo: Clean
# Compile
python web2py.py -S eden -M -R applications/eden/static/scripts/tools/compile.py
# @ToDo: Catch errors
# @ToDo: Pack
# @ToDo: Download with filename

Test

Import the app with a new name & Test

Upload to LaunchPad

Note: As of January 2012, BZR/Launchpad info for eden is deprecated. Please visit the GitHub page. Thanks.

Update Windows Installers

Update Wiki

Update Demo

  • Update Web2Py if necessary 
    cd /home/web2py/applications/eden
git pull

Alternate approach:

See Also

DeveloperGuidelines

Last modified 9 years ago Last modified on 03/13/16 21:24:01
Note: See TracWiki for help on using the wiki.