first go at a WS deployment procedure

docker-compose.local.yml

@@ -85,6 +85,32 @@ services:
     profiles:
       - schema-dev
 
+  # Used for doing a DB migration on dsoc-test
+  # Run the command `docker compose -f docker-compose.local.yml --profile schema-test up schema-test` and the migration will run
+  schema-test:
+    build:
+      context: ./schema/
+      dockerfile: Dockerfile.local
+    command: ["./bin/run-migrations.sh", "dsoc-test"]
+    volumes:
+      - ./schema:/code/schema
+      - ~/.capo:/home/ssa/capo
+    profiles:
+      - schema-test
+
+  # Used for doing a DB migration on dsoc-prod
+  # Run the command `docker compose -f docker-compose.local.yml --profile schema-prod up schema-prod` and the migration will run
+  schema-prod:
+    build:
+      context: ./schema/
+      dockerfile: Dockerfile.local
+    command: ["./bin/run-migrations.sh", "dsoc-prod"]
+    volumes:
+      - ./schema:/code/schema
+      - ~/.capo:/home/ssa/capo
+    profiles:
+      - schema-prod
+
   workflow:
     build:
       context: .

docs/source/deployment.rst

 Deployment
-==========
+============
 
-.. warning::
+The following pages outline the deployment steps for various Workspaces Environments.
 
-   Fill this in with deployment steps.
+Contents:
+
+.. toctree::
+   :maxdepth: 2
+
+   deployment/*
+EOF

docs/source/deployment/production_deployment.md

+# Workspaces Production Deployment
+
+### Before Deployment
+
+* Create Release Notes
+* Update <span style="color:cornflowerblue">dsoc-prod</span> Capo Properties
+* Back up Production Database (If deploying in conjunction with AAT, the AAT procedure covers this step)
+* Send 'Beginning Deployment' notification to <span style="color:cornflowerblue">ssa-announcements@nrao.edu</span>
+
+
+
+### At Deployment
+
+* Checkout the latest release candidate branch.
+* Run any needed schema migrations on the production database: <span style="color:cornflowerblue">
+  docker compose -f docker-compose.local.yml --profile schema-prod up schema-prod
+  </span>
+* Tag the release candidate branch for production deployment: 
+  <span style="color:cornflowerblue">
+  {version#}
+  </span>
+  * This tag is then automatically pushed up to the production server as part of the WS CI/CD pipeline.
+
+
+### After Deployment
+* Ensure test PEXes have been updated on the cluster after deployment to production. Check the build dates
+  in the workspaces/sbin/ area.
+* Smoke test production
+* Send 'All Clear' notification to <span style="color:cornflowerblue">ssa-announcements@nrao.edu</span>
+* Merge release candidate branch back into main branch to pick up any fixes made during testing

docs/source/deployment/test_deployment.md

+# Deploying to the WS Test Environment
+
+## Two Types of Test Deployments
+While Workspaces development is handled in an Agile manner, the release cycle itself is handled through
+waterfall, partially due to occasional reliance on AAT/PPI release cycles. A WS Release Candidate will be
+made available for acceptance testing by the WS Stakeholders at TRR stage (after final sprint review)
+and then go through integrated Stakeholder testing and ORR stage before being approved for Production
+Deployment.
+
+## End of Sprint Deployment (Feature Testing)
+
+#### At the end of each WS Sprint:
+
+* Run any needed schema migrations against the test database: 
+<span style="color:cornflowerblue">
+docker compose -f docker-compose.local.yml --profile schema-test up schema-test
+</span>
+* Update any needed Capo properties
+* Tag main branch as:
+  <span style="color:cornflowerblue">
+  end-of-sprint-{#sprint}
+  </span>
+    * This tag is then automatically pushed up to the testing server as part of the WS CI/CD pipeline.
+* Ensure test PEXes have been updated on the cluster after deployment to test. Check the build dates
+in the workspaces/sbin/ area.
+
+You should now be ready for Sprint Review.
+
+## Release Candidate Deployment (WS TRR)
+
+#### After Final Sprint Close:
+* Create a release candidate branch: <span style="color:cornflowerblue">release/WS-{#version}-RC1</span>
+  * It might be necessary to fix bugs found during Stakeholder testing, but we also don't want to pollute
+  the release candidate with any ongoing work for the next release. This will be merged back into main as
+  part of production deployment.
+
+* Verify that the test database already has the expected migrations in place.
+
+* Verify <span style="color:cornflowerblue">dsoc-test</span> Capo properties
+
+* Tag the release candidate branch: <span style="color:cornflowerblue">{#version}-rc1</span>
+  * This tag will then autodeploy to the testing server as part of the WS CI/CD pipeline.
+
+* Ensure test PEXes have been properly updated on the cluster.
+  * Check the build dates in the workspaces/sbin/ area.
+  * If ingest changes were made, ensure the current PEX was copied over from the dev environment.
+
+* Notify the Product Owner (Mark Lacy), VLASS Scientist (Amy Kimball) that the release candidate has
+been deployed to test and is available for integrated testing. Note: WS, AAT, and VLASS will 
+usually end up being tested together due to functionality interdependence.
+
+You should now be ready for Stakeholder Testing.