wiki:MilestoneReleasesHowTo

How to release a milestone

Welcome to the hitchhiker's guide to Rox releases! :) Milestone releases are done by release coordinators, a role that different people can volunteer for. A solid understanding of Rox code, the release cycle and good communication skills as well as a positive attitude are mandatory for taking this role. A coordinator candidate should have participated in at least two release cycles by contributing code and performing acceptance tests. They also need to have the backing of a majority in the developer team.

If the release coordinator does not have access to the live deployment, they need to team up with a live server admin, currently these are jsfan and planetcruiser. The current release cycle was developed and documented by planetcruiser. Please ask him or other former coordinators if anything needs clarification. If you have minor improvements, please add them by editing this page. Major changes should be discussed on the developer mailing list first. Now, off you go, happy releasing! :)

When to release

  • At least 2 days after all tickets have been closed and a last testing call has been made to the developer mailing list and the tester group on BeWelcome.
  • Don't rush. Quality is more important than releasing on a certain date. Reschedule if just before a release major issues within a fix arise or a change that is about to be introduced is still discussed by developers.
  • Try to schedule the live deployment during off-peak times (week day, early during a CET day) - if compatible with coordinator's and live admin's schedule.
  • Give at least 4 hours after the release for emergency hotfixes. Don't release and go to bed or out for drinks! ;)
  • Don't make the release a party itself - take responsibility for a community of over 30000 travellers that might depend on the website and enjoy the fruits of your labour after the release.
  • Make sure to be present in the #bewelcome IRC chat before, during and after the release to inform others and react quickly to feedback.
  • Announce changes to release time and date to the dev list, so others get the chance to be present during the release.
  • Focus. All eyes and hands need to be on the current release to publish it in the best way possible. Following releases can be planned and worked on once the current release is out the door.

Release steps

  1. Review tickets and code
    • Make sure all tickets are closed and tested
    • Go through all tickets once again and review if the solution solves the issue initially reported in the ticket description, issues reported in the ticket comments are of secondary concern. Reopen tickets that have not fully been solved
    • If grave new issues are raised in the ticket comments, make sure new tickets have been created and that those tickets mention the current ticket in the "Related tickets" part
    • Look through commits and ensure that newly added and changed code follows the ProgrammingGuideline. If not, contact the committer or fix it yourself. But this should not delay the release, so this is mainly intended as a notice for future commits
  2. Make sure to break caches
    • A common source of errors are outdated versions of JavaScript and CSS files in users' caches after a release. We address this by adding "?1" or increments of it to resource file includes. Find out which resource files have been modified since the last major release by typing this:
      git checkout master
      git pull
      git checkout develop
      git pull
      git diff --name-only --diff-filter=M master | egrep "\.(js|css)$"
      
    • Do a full text search for the filenames you get above and make sure they got a "?1" (or higher) at the end, for example searchmembers.js?1 in main.js.
    • For bigger releases it might be wise to test cache breaking by following this example: http://lists.bewelcome.org/pipermail/bw-dev-discussion/2012-December/009961.html
  3. Write changelog
    • Create new wiki page for changelog, naming convention is "Changelog_x.x", see Changelog_0.7 for example and use Changelog_x.x as a template.
    • Where possible use past tense verbs to describe changes, so it's clear what has been done. Start lines with "Added", "Improved", "Changed", "Fixed" and "Removed". The ticket title itself often is not enough to describe a change.
    • First list all "Added" and "Improved" items, because that's what most people are interested in, then "Changed" functionality. "Fixed" and "Removed" go last, because users expect things to work anyway and removed items should only be removed if their disappearance won't be noticed, so they are not so important in the list.
    • If there is a ticket for the change, link to it at the end of the line: "(ticket #666)".
    • Check https://gitorious.org/bewelcome/rox/commits/develop for commits since last release that have no ticket and add them as well and add "(no ticket)" at the end
    • Thank contributing users by stating their BeWelcome user name, not their trac name. Use alphabetical order to stay neutral. Check in commits and ticket comments for code contributors and testers. Don't forget anyone! ;)
    • Edit milestone page and add link to changelog, see 0.7 for example.
  4. Merge develop into master
    git pull
    git checkout master
    git merge --no-ff develop
    git push
    
  5. Add tag for release, for example:
    git tag -a v0.7 -m "Bugfixing and feature release 0.7"
    git push --tags
    
  6. Deploy www from master via deploy.sh on puma (pending documentation, can currently only be done by planetcruiser and jsfan)
  7. Go through smoke tests below
  8. Make sure cron jobs (e.g. mailbot) run without errors, check bw-admin mailing list for error reports
  9. Edit milestone and tick "Completed"
  10. Write about release via blog post in community news (blog post needs to be accessible without login)
  11. Announce new/modified translation strings in this thread: http://www.bewelcome.org/groups/60/forum/s2330
  12. Announce release (with link to community news blog post):

Smoke tests after release

Here are a few things you should test after a release to ensure the basic functionality of the site, even if the tested features should not be affected by the fixes for the release. Rox goes mysterious ways sometimes and everything is related with everything. ;)

  1. Send a message to another member, see if the message was received after no later than 5 minutes. Check if you can access your message archive.
  2. Do a search via map and click on a couple of profiles. See if profile comments are visible.
  3. Browse through the country and places lists. Click on some profiles.
  4. Log out and do the same profile search and clicking.
  5. Go to the forums and click on a few threads.
  6. Open a few galleries.
  7. Click on some blog posts.

Please add to this list if you think some other basic features should be tested.

Former release coordinators

  • planetcruiser (10+ releases)
  • jsfan (2+ releases)
  • shevek (3+ releases)
  • mahouni (1 release)
Last modified 4 years ago Last modified on Jun 16, 2013 8:22:20 AM