• gresq_SPD_1.1.0.md *
• Draft SPD **
  

The latest production version of this application is hosted on nanoHUB for public use:
https://nanohub.org/tools/gresq

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment notes (below) for info on how to deploy the project on nanoHUB.

The code in the repository uses submoded fro mthe GSAImage and GSARaman repos. Be sure to use --recurse-submodules when cloning:

$ git clone --recurse-submodules git@github.com:nanoMFG/GSAMain.git

If already cloned:

$ git submodule init
$ git submodule update

See:
https://git-scm.com/book/en/v2/Git-Tools-Submodules
for more details on working with submodules.

$cd src
$python -m gresq

Install anaconda3 or miniconda3, then:

conda create --name gresq-3.6 python=3.6
conda env create -f <srcdir>/.conda/env_gresq_[osx|linux]_3.6.yml
conda activate env_gresq_[osx|linux]_3.6

From the repository root:

pip install ./gsaraman
pip install .

or for development:

pip install -e .

Additional prerequisites for testing are:

pytest
factory_boy

After installing, run the following from the repository root:

pytest -v

Note, to avoid broken DB tests:

pytest -v --ignore=test/database/models --ignore=test/util

Overview of deployment:

1. Code changes accumulate in development.
2. devel branch is tested on nanoHUB.
3. Create a Release candidate.
4. Carry out release procedure and database migration procedure (if neccasary).
5. Install release on nanoHUB and approve changes.

• All testing should be done against gresq_testing or gresq_development NOT gresq_production.
• Code changes should be tested against development database before deployment.

The database migration process for a particular release should always be tested on the development database before attempting to migrate the production DB. For changes that require a migration, this should happen during step 2. above.

1. Drop all tables from development DB
2. Dump production DB to a file.
3. Create tables from updated models
4. Load production data dump into development tables*
5. Test devel code using

*Note: In some cases, the mirgration may require changes to the dumpped data in order to be compatable with the new schema. This should be handled case by case.

1. Shut down external access to DB (or perhaps maintain DB for old version temporarily)
2. Approve code chnges for new nanoHUB version
3. Dump production table to file.
4. Drop all production database tables.
5. Re-create tables from updated models.
6. Load production data from dump.

• Load latest code to your nanoHUB workspace using git command line in the nanoHUB workspace.
• Run the middleware/invoke script to launch the application into your workspace. Note: we need a way to ensurte these test invocations of the tool do not run against the production DB.

See also the list of contributors who participated in this project.

Copyright University of Illinois, 2018-2019.

Distributed under the terms of the APACHE2 license, GrResQ Dashboard is free and open source software.