your assistant while on releaseduty
In the spirit of taskwarrior, releasewarrior is a tool that manages and provides a checklist for human decision tasks with releases in flight while providing documentation and troubleshooting for each task.
Rather than manually managing a wiki of releases, releasewarrior provides a set of commands to do this work for you.
get copy of releasewarrior
git clone https://github.com/mozilla/releasewarrior
cd releasewarrior
install it in your virtual python environment
mkvirtualenv --python=/path/to/python3 releasewarrior
python setup.py develop
Using the develop target ensures that you get code updates along with data when pulling in changes.
If you are on NixOS or use the Nix package manager, you can simplify the steps
above by running nix-shell requirements.nix or nix-shell requirements.nix --run zsh to use your favourite shell.
If you change requirements.txt or want to refresh the frozen versions used by
nix-shell, run the following command, which requires
pypi2nix
pypi2nix -V "3.5" -r requirements.txt
releasewarrior is made up of a number of subcommands. create, update, and postmortem are the main ones.
Each of those commands will do the following in order:
- create/update a data json data file that tracks a current release in flight
- that data file is then rendered against a wiki template for a nice presentation layer.
- finally, the command's changes to the data and wiki file are automatically committed using your user git config so each change is tracked.
pro tip: use release --help and release <subcommand> --help lots
prior to each command your local master can not be behind origin/master. this is enforced and by design so that you always have the most up to date state
usage:
$ release create $PRODUCT $BRANCH $VERSION
example:
$ release create fennec release 17.0
what happens:
- date file created: releasewarrior/releases/fennec-release-17.0.json
- wiki file rendered from data: releasewarrior/releases/fennec-release-17.0.md
- change is committed: commit
usage:
$ release update $PRODUCT $BRANCH $VERSION --$UPD
example:
say you want to update ff 18.0b3 by checking off submitted to shipit, adding a link to taskcluster graphid, and add an issue that came up with timing out.
$ release update firefox beta 18.0b3 --shipit --graphid 1234567 --issue "win64 l10n hg timeout, retriggered"
notice: you can update a release with many things at once. use release update --help to see all the update options
what happens:
- data file updated: releasewarrior/releases/firefox-beta-18.0b3.json
- wiki file rendered: releasewarrior/releases/firefox-beta-18.0b3.md
- change is committed: commit
example:
this time RC 15.0 current buildnum has been abandoned. you can simply pass --buildnum-aborted and a new buildnum will start being tracked
$ release update firefox release-rc 15.0 --buildnum-aborted
what happens:
- data file updated: releasewarrior/releases/firefox-release-rc-15.0.json
- wiki file rendered: releasewarrior/releases/firefox-release-rc-15.0.md
- change is committed: commit
now let's do some more interesting things
usage:
$ release status
what happens:
status will tell you all of the current releases in flight. It does this by telling you which tasks remain and what the current issues are:
releasewarrior: DEBUG RUNNING with args: status
releasewarrior: INFO getting incomplete releases
releasewarrior: INFO ensuring releasewarrior repo is up to date and in sync with origin
releasewarrior: INFO fetching new csets from origin to origin/master
releasewarrior: INFO RELEASE IN FLIGHT: firefox 46.0b1 16-05-19
releasewarrior: INFO incomplete human tasks:
releasewarrior: INFO * submitted_shipit
releasewarrior: INFO * emailed_cdntest
releasewarrior: INFO * post_released
releasewarrior: INFO latest issues:
releasewarrior: INFO * testing 1 2 3
releasewarrior: INFO RELEASE IN FLIGHT: fennec 46.0 16-05-19
releasewarrior: INFO incomplete human tasks:
releasewarrior: INFO * submitted_shipit
releasewarrior: INFO * pushed_mirrors
releasewarrior: INFO * post_released
releasewarrior: INFO latest issues:
releasewarrior: INFO * none
and my favorite command..
usage:
$ release postmortem $DATE_OF_POSTMORTEM
example:
$ release postmortem 2012-01-01
what happens:
- create a postmortem data file: releases/POSTMORTEMS/2012-1-1.json
- for all releases that have all human tasks completed a. add their issues to the postmortem data file b. move the original release tracking data/wiki files into releases/ARCHIVES
- generate postmortem wiki file based on equivalent data file: releases/POSTMORTEMS/2012-1-1.md
- change is committed: commit
bonus: one nice thing about this is the command is idempotent. in other words, you can call this as many times as you and it will only append to the given $date postmortem file as it finds completed releases!
of course, given that the data is just a json file and changes are tracked by this repo's revision history, you can always manually update the data and have the tool re-create the wiki presentation against your data changes
usage:
$ vim releases/firefox-esr-27.0esr.json # change some value from false to true
$ release sync firefox esr 27.0esr
what happens:
- data file is re-read but not updated
- wiki file is re-rendered with the data is just got from current file
- change is committed (if there was any change)
if commands scare you and you want full control, you could even update the data manually, update a wiki manually, and just commit the changes yourself.
Sometimes you might need to have special requirements or steps for a future release. Since they are one offs, you don't want to add them to the templates. The solution is to add upcoming releases to the releases/FUTURE/ dir. See future release support for more details.
- releasewarrior only knows about the
originremote (whatever that points to in your local copy's .git/config. It also doesn't have knowledge of any branches so best stay onmaster.- however saying that, feel free to fork this repo to play around. that way you don't need to rewrite revision history after you are done experimenting
- there are not templates for Thunderbird yet. I'll add support for that soon
- there are no tests because I'm a bad developer