nmdp-bioinformatics / gfe-db

Graph database representing IPD-IMGT/HLA sequence data as GFE
https://gfe-db.readthedocs.io
GNU General Public License v3.0
9 stars 15 forks source link

Issues for 1.0 #89

Open pbashyal-nmdp opened 1 year ago

pbashyal-nmdp commented 1 year ago

Issues for 1.0

chrisammon3000 commented 1 year ago

Some considerations for task # 2 (New Makefile target make vpc that builds the network (optional)):

If multiple gfe-db environments are be created in the same account, some environment variables will need to be different to avoid conflicts, so 1) there should be a way to manage this locally 2) we will want safeguards in place to prevent deploying using the wrong environment variables 3) Resource name conflicts will have to be addressed

  1. Managing environments locally One solution I would offer is to use multiple .env:
    .env.dev
    .env.qa
    .env.prod

Where we append the $STAGE variable to .env.env.${STAGE} in the Makefile so it only includes those variables.

  1. Safeguards against deploying to the wrong environment

    • Print the environment to the console and ask user to confirm before deploying or updating, the user should confirm that they are deploying with the correct $STAGE value
    • Create a change set and ask user for confirmation before updating
    • CloudFormation stacks are now tagged with the git branch, so we can detect if a deployment update is being made from a different branch than what the tag is and ask for user confirmation before continuing. (Deploying the wrong branch to the wrong environment will cause problems)
  2. Avoiding resource name conflicts Shouldn't be an issue as long as every named resource has the $STAGE variable in it's name.

chrisammon3000 commented 1 year ago

Tasks 1 & 2 are ready for review:

The points I mentioned above for managing environments locally, safeguard against deploying to the wrong environment, and avoiding resource name conflicts are implemented.

Task 3 (Keep track of IMGT commits to GFE DB) just needs to be merged with the most recent PRs first. It includes validation (task # 4) of build outputs and load results but does not include testing yet.