...
- The scheduledb branch will be merged into the master branch. The master branch contains the state of the current tssg.tech web site.
- The database will be compared to the data on the current site and updated to match
- we should split up the List All pages and each Web Team member update his/her collection data vs the True Data
- (is the True Data stored on Confluence & copied into TSSG.tech? or is current site the Single Source of Truth?)
- afterward, do the same for the static pp in the Site folder (nothing should be different, can we automate this step?)
- later (maybe after staged to QA?) Jim thought of another check but can't remember it now
- Final step: see to it somehow that this (newest) data is in the (initializing) db saved in the Git repository
- A Jenkins project will deploy the master branch to a staging (i.e. QA) endpoints.
- decide the names of the services' subdomain endpoints (update.tssg.tech? etc.)
- configure Nginx to reverse-proxy them to the underlying services
- configure Jenkins
- execute the deploy
- Automated and manual tests will be run against the staging area. This will verify that the merge has happened successfully before moving to the next step in the pipeline. Corrections will be made if needed until the staging area quality can be assured.
- create "smoke" tests to verify service interconnectivity
- enhance code coverage for all UX features
- Another Jenkins project will deploy the master branch to the production endpoints.
- Automated and manual tests will be run against the production endpoints. This will verify the quality of the production endpoints. Corrections will be made if needed until the production area quality can be assured.
...