Cell Browser Release Process

For the buildmeister

This first section covers the release process from the view of the buildmeister.

Setting Up the Environment for the Build

These instructions assume you're running bash.

Check and see if you have the repository installed already, if not clone it:

 git clone https://github.com/ucscGenomeBrowser/cellBrowser

Make sure you have a github account.

On your github account, create an authorization token, see the following for instructions (make a separate token for the cellBrowser): https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token The token will only be visible once, so copy the token, copy it to ~/.githubtokens or similar, and make that file 600 permissions

 vim ~/.githubtokens
 # copy key and save file
 chmod 600 ~/.githubtokens

Ensure you have access to PyPI. You have two options:

1. have Max grant you his permissions into your ~/.pypirc file
2. create a PyPI account, copy those credentials to your ~/.pypirc, have Max grant your user access to the cellBrowser package

Ensure the twine package is available to your user, the following command should work and print 'success':

 /usr/bin/python3.6 -c "import twine; print('success')"

If it doesn't work, run the following command to install twine locally:

 pip3 install twine --user

Ensure the requests package is available to your user, the following command should work and print 'success':

 /usr/bin/python3.6 -c "import requests; print('success')"

If it doesn't work, run the following command to install requests locally:

 pip3 install requests --user

Change directory into cell browser git hierarchy build directory.

 cd ~/cellBrowser/build 

Make sure you're on the develop branch.

 git checkout develop
 git pull

Get the version number from the redmine build ticket, then update the file buildEnv.sh to change CBVERSION to CBLASTVERSION and CBDATE to CBLASTDATA and add new CBVERSION and CBDATE strings. See the file for examples. Source the file then check it in.

 vi buildEnv.sh
 source buildEnv.sh
 git commit buildEnv.sh

Running the git reports

Run the git reports.

 ./doGitReports.sh

The reports appear here:

  https://genecats.gi.ucsc.edu/CB-git-reports/

Assign code reviews. Repeat reports if reviews result in changes. Move on when code reviews are finished without requested changes.

Tag and Push release

Change directory to build directory and set environment variables (if not already done)

cd ~/cellBrowser/build 
source buildEnv.sh

Merge develop branch with master branch, tag it, and make PIP release. You'll need to enter your github username and passcode twice (for the merge push, and for the tag push).

  ./doPush.sh

Update the ticket with the location of the PIP release.

 https://pypi.org/project/cellbrowser/$CBVERSION

Assign the build shepherd in the ticket.

QA reviews

Once the pip release is done, QA installs on cells-beta and tests the software there. If all is good, then they push it to the RR. If a major issue arises while testing on beta, QA kicks it back to the engineers. If changes are made to develop after the PIP push, start from the beginning with an incremented version string. There is no build patch mechanism currently.

For Cell Browser QA

This section covers the release process from the view of QA.

Step 1: Decide it's release time

The first step is to determine: is it time for a release? There's currently no release schedule, but it's best to do a release after a new feature has been added and is stable or after a round of bug fixes.

Step 2: Make a release ticket

In the Cells Redmine, make a ticket with the 'Release' tracker. Set the 'Title' and 'Version' fields to 'vN.N.N', where N.N.N is the version number of the release. Once you've made the ticket, add all of the 'Bug' and 'Feature' tickets that are part of that release to the 'Related Issues' section.

Step 3: Wait for pip release

Once you've made the ticket, work with Max and the buildmeister to coordinate the pip release (see Cell_Browser_Release_Process#For_the_buildmeister above).

Step 4: Upgrade code on cells-beta

After the pip release is done, it's time to update the code on cells-beta.

Install the cell browser from pip

pip install cellbrowser

Upgrade the code on beta:

cbUpgrade --code -o beta

Test UI on beta

Test the UI on beta using the instructions on the Cell_Browser_testing page. Essentially, you want to ensure that the software works as expected on cells-beta.

If you run into serious issues while testing on cells-beta, report them in the release ticket and hold off on pushing to the RR.

Step 5: Push code to RR

Once everything looks good on cells-beta, it's time to push things to the RR via

sudo cellsPush 

Test UI on RR

Once the new software is on the RR, then give it a quick test to ensure that the push went smoothly. It doesn't have to be as in-depth of a test as on cells-beta, but a quick run through of any bugs and major features fixes would be ideal.

Step 6: Post-release wrap-up

Once the release is done, close the 'Release' ticket and uninstall the pip version of the Cell Browser:

pip uninstall cellbrowser