Cell Browser Release Process: Difference between revisions

From Genecats
Jump to navigationJump to search
Line 27: Line 27:
If it doesn't work, run the following command to install twine locally:
If it doesn't work, run the following command to install twine locally:
   pip3 install twine --user
   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.
Change directory into cell browser git hierarchy build directory.
Line 92: Line 97:
==Step 4: Upgrade code on cells-beta==
==Step 4: Upgrade code on cells-beta==


After the pip release is done, it's time to update the code on cells-beta. We install and update the code from the pip version so that cells-beta and cells are on a specific, stable version of the software.  
After the pip release is done, it's time to update the code on cells-beta.


Install the cell browser from pip:
Install the cell browser from pip


  pip install cellbrowser
  pip install cellbrowser
Line 106: Line 111:
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.
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.
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==
==Step 5: Push code to RR==
Line 120: Line 125:
==Step 6: Post-release wrap-up==
==Step 6: Post-release wrap-up==


Once the release is done, close the 'Release' ticket and all of the related Bug/Feature tickets that were part of that release. If there are open issues with any of the related tickets, either leave them open or create a new ticket focused on that open issue. (If the old ticket has a lot of discussion, it can be easier to just create a new ticket to keep the discussion focused.)
Once the release is done, close the 'Release' ticket and uninstall the pip version of the Cell Browser:
 
Also, uninstall the pip version of the Cell Browser from whatever conda environment you may have installed it in:


  pip uninstall cellbrowser
  pip uninstall cellbrowser

Revision as of 21:27, 23 January 2023

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

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