Servers Deployment environment

We have 4 VMs in deployment

• the username is pub
• they run in RAILS_ENV=production mode
• they each have MySQL database instance running locally

Machines

Note: the library is the "Pub/sul-pub" team and is the maintainer of this harvesting code within SUL. The "CAP/Profiles" team is in the School of Medicine and maintains the CAP/Profiles website code at https://profiles.stanford.edu

Note that "CAP" stands for "Community Academic Profiles" and is the previous name for the "Profiles" system. It is NOT capistrano.

Environment	Alias URL (for historical reasons)	Purpose	SLA	How to Deploy	Notes
sul-pub-prod	https://sulcap.stanford.edu or https://sul-pub-prod.stanford.edu	Production (i.e. the API that that the Profiles system at profiles.stanford.edu connects to). The Profiles team uses this in their production environment.	Medium	cap prod deploy	harvests every three days for data - see the https://github.com/sul-dlss/sul_pub/blob/main/config/schedule.rb file
sul-pub-stage	https://sul-pub-stage.stanford.edu	DLSS's sul-pub staging environment. Useful for SUL only testing with no concerns that our experiments impact the Profiles team	none	cap stage deploy	Does not connect to any Profiles system. No automatic harvesting.
sul-pub-cap-dev	https://sul-pub-cap-dev.stanford.edu	The Profile's team development environment (i.e. the API that cap-dev.stanford.edu connects to). Used for developer integration testing and not shown to stakeholders. A good environment for testing development changes.	none	cap qa deploy	The actual host name is sul-pub-cap-dev-a and is also the name of the shared_configs branch used. The reason for the -a is historical and due to previous use as a separate server for a Profiles upgrade. An alias allows access via sul-pub-cap-dev. No automatic harvesting.
sul-pub-cap-uat	https://sul-pub-cap-uat.stanford.edu	The Profile's team UAT environment (i.e. the API that cap-uat.stanford.edu connects to). Used for stakeholder and UAT testing with the Profiles team. Since it can be shown to stakeholders, it should be reasonably stable. Use -dev for developer focused integration testing or for testing with real data that may be more experimental.	Low	cap uat deploy	bi-weekly harvests for data - see the https://github.com/sul-dlss/sul_pub/blob/main/config/schedule.rb file.