It's a long way to the RR

Overview

Data and program code go from hgwdev to hgwbeta to the RR. You modify something on hgwdev. But when and how does it land on the RR?

All Routes

There are five different routes that a change can take to get to the RR:

1. CGI code, related .ra, .js and .css files: stored in git, moved from dev to beta to the RR via the build process, which can take from one to three weeks. Back-pushed from RR to beta-public after release.
2. trackDb: stored in git, sent to dev/beta/beta-public via makes, pushed to the RR, happens all the time
3. htdocs static html files: similar to trackDb, pushed from hgwbeta to the RR all the time
4. /gbdb: pushed straight from hgwdev to the RR (because hgwbeta and the RR share their /gbdb)
5. mysql tables: pushed from hgwdev to hgwbeta and then from hgwbeta to the RR

The "build process" is run by the build meister at certain days. The build meister compiles the git master branch and copies the result to hgwbeta and then to the RR one week later.

As trackDb is pushed constantly, parts that should not be active on the RR have to be marked with "release alpha". New tracks should always be marked with "release alpha", QA will then change "alpha" to "beta" or "public" as the track is getting ready.

Route combinations (unusual)

Our release system gets very complex when changes touch combinations of the above "routes".

Examples:

• cgi and htdocs: A change to a static html file that requires a CGI change:

1. Commit the CGI change, wait until it goes through code review etc and is on the RR
2. Do not commit the html page, as someone else may push it to the RR.
3. change the html page, commit and request a push from hgwdev to the RR

• trackDb and gbdb: A change to a bigBed file that adds a field that is referenced from a trackDb statement (e.g. mouseOverField)

1. duplicate the trackDb entry, the old one has "release public", the new one "release alpha"
2. The release alpha version gets the new line with "mouseOverField"
3. modify the bigBed file on hgwdev BUT GIVE IT A DIFFERENT NAME (as hgwbeta and the RR share /gbdb)
4. request a push to hgwbeta and tell QA to update the release tag, first to beta, then to public, when it goes to the RR

• sql and cgi: a change to a cgi that requires an additional field in a mysql table

1. change the CGI and code it in a way that it can detect if the old or new table format is used by...
   1. looking for a trackDb statement that indicates the version
   2. looking at the track/table name (e.g. wgEncodeTf and wgEncodeTfV2)
   3. looking at the table schema (checking if the field is present)
2. make sure that the new table has a different name than the old table. This makes everything easier.
3. create the new table on hgwdev
4. wait until the build process has copied your change to the RR, then request a push of the new table to beta and then the RR. If you need different trackDb statements for some reason, make sure you use release tags on these

• htdocs and css

1. change the .css first, wait until it's through the build process and on the RR
2. now change the html pages and request a push to the RR