Deployments
...
Go to build-dev-stack
Make any change needed to configuration (new config values, update beanstalk solution…)
Build with Parameters > Specify instance number (N+1), beanstalk numbers (0 if regular/non patch), versions (from builds above) and git branch for the stack builder (matches the instance number)
After the build is done, go to SynapseDev AWS console / Elastic Beanstalk and restart the servers for the environments
Go to dev-link-dns-to-alb to configure the stack just deployed as a staging stack
Configure > Execute shell
In the command, for ‘repo.staging.dev.sagebase.org’ and ‘portal.staging.dev.sagebase.org’ replace ‘none’ by ‘repo-dev-<N+1>-<beanstalk-number>’ and ‘portal-dev-<N+1>-<beanstalk-number>’ where <N+1> and <beanstalk-number> are the values specified for the dev stack deployed above
==> This is going to move the instances in the target groups for the staging ALB (i.e. make stack <N+1> the staging stack. The operations takes about 5 minutes.
While the linking is happening, setup a mySQL connection to the new stack repo database.
dev-<N+1>-db.cdusmwdhqvso.us-east-1.rds.amazonaws.com as endpoint
dev-<N+1>user as user
dev-<N+1> as db
To verify that you have the correct prod and staging instance of the dev stack
go to https://repo-prod.dev.sagebase.org/repo/v1/version ==> N
go to https://repo-staging.dev.sagebase.org/repo/v1/version ==> N+1
Go to migrate-dev-stack
Migrate the stack by running the job
Should take 2-3 attempts to get it down to about 5 minutes
When at 5 minutes, connect to the ‘prod’ dev stack and set it to Read-Only mode (the migration job sets the destination to RO and leaves it RO).
After the final migration, both stacks are in RO mode. Verify that all types displayed have null values for (min,max) [these are empty tables]
Go back to dev-link-dns-to-alb, this time to config the new stack as the ‘prod’ stack
Configure > Execute shell
In the command, for ‘repo.prod.dev.sagebase.org’ and ‘portal.prod.dev.sagebase.org’ replace ‘N’-<beanstalk-number> by ‘<N+1>-<beanstalk-number>’ (i.e. make the new stack the prod stack) and for ‘repo.staging.dev.sagebase.org’ and ‘portal.staging.dev.sagebase.org’ set them again to ‘none’ (there is no ‘staging’ stack except for migration purposes)
==> Again, the operations takes about 5 minutes
In the database for the new stack, set the status to read-write mode and verify that the prod stack is in read-write mode at https://repo-prod.dev.sagebase.org/repo/v1/status .
In the Synapse Dev AWS console, go to CloudFormation and delete the stacks for portal-dev-<N>, repo-dev-<N> and workers-dev-N.
Run the synapsePython client integration tests
Go to http://build-system-ops.dev.sagebase.org:8080/job/synapse-python-client-integration-test-prod/ > Build Now
Go to http://build-system-ops.dev.sagebase.org:8080/job/synapse-python-client-integration-test-staging/ > Build Now
NOTE: If you wait more than a few minutes to run these, hold on for a while else whatever they expect on the queues will start mixing with the replaying of messages and tests will time out. Sometimes happens as soon as the second (dev branch) test.
If there is any error, open a Jira and work with the client dev team to resolve.
...
Go to http://build-system-ops.prod.sagebase.org:8080/job/build-synapse-prod-bind-nlb-to-alb/
Configure
In Execute Shell Command, edit the values for ‘repotst.prod.sagebase.org’ and ‘tst.synapse.org' from ‘none’ to ‘repo-prod-<stack-instance>-1’ and ‘portal-prod-<stack-instance.-1’, where <stack-instance> is the release number you’re on (e.g. ‘473’)
Build with parameters
CAUTION: Make sure you enter the correct parameters for (<release-number>-<beanstalk-number>) as the running stack (i.e. what was input when staging was promoted to prod above).
...
Go to http://build-system-ops.prod.sagebase.org:8080/job/build-synapse-prod-bind-nlb-to-alb/
Configure
In Execute Shell Command, set the values for ‘repotst.prod.sagebase.org’ and ‘tst.synapse.org' back to ‘none’
Build with parameters
CAUTION: Make sure you enter the correct parameters for (<release-number>-<beanstalk-number>) as the running stack (i.e. what was input when staging was promoted to prod above).
...