Staging Environment
The staging environment is a replica of production and acts as a sandbox for testing deployment manager updates, updates to the base platform, as well as training for implementation team members and migration team members within an environment that is entirely separate from production.
Staging deployment manager: https://cloud-manager.cloud2-stg.rezfusion.com/
Production Environment
The production environment is our blue/green service that has live or in-implementation clients on it. This environment has a separate canary and production service, just like the staging environment.
Unlike the staging environment, though, the production environment has real live clients in it.
Production deployment manager: https://ngen-manager.rezfusion.com/
Logging into CircleCI
Use your GitHub account/work e-mail address to create a CircleCI account. It should be associated with the repositories from GitHub your account has access to. If additional access is needed, create a service ticket with the Inhabit IQ Service Desk with desired updates and access levels.
The latest code changes are built, both for our staging environment and our production environment, within the iiq-wp-platform project in CircleCI.
When viewing the built jobs you will notice we have a build-staging-image and a build-production-image job. The staging image sha256 value is only able to be used on the staging deployment manager releases. Whereas the production image sha256 value is only valid for the production deployment manager releases.
CircleCI Dashboard: https://app.circleci.com/pipelines/github/PropertyBrands/iiq-wp-platform
Finding the Image Hash
Select the relevant job for the environment you want to deploy to. The output at the end of the job should include the sha256: image hash value. Copy this value, as-is (including the sha256: portion.) This value will be the value used by the deployment manager - again verifying the stage image for staging cloud2 environments and the production image for the production ngen-manager environment.
In this example, the release hash value is sha256:082652ff4ed311c5caa049190d4b6f2f57c22cfc7f45a5d55ea2c7b05953b59b.
Deploying to the Canary Environment
Once the release hash value is identified, navigate to the appropriate deployment manager for the environment related to the image (production or staging.)
Once within the deployment manager, verify the desired service is set to be canaried. You can see which websites live on which service, which may influence which service you want to canary. You may also move a single site to a different service (i.e. if a site with a bug to test a fix for is on blue, you can canary changes to green and move the site to the green service.)
Place the sha256 value identified in the previous step into the “Update Canary Image” field. This will trigger the codebase to update for the green service and an update to rollout for all sites on the green service (flushes site caches, etc.)
Once the changes are verified then a given ticket (or set of tickets/release) is/are ready for QA.