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 install
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.
- releasewarrior only knows about the
origin
remote (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