Canvas environments beta and test are regularly overwritten with the content and configurations of the production environment. This causes issues where e.g. having a discovery page and navigating to the beta instance, company.beta.instructure.com, redirects you to the production discovery page after a environment refresh. Users are then unknowingly logged in to the production environment while thinking they are in beta. I would thereby like to propose an idea where an administrator have the ability to control what is overwritten during an environment refresh and ensure that configurations such as the Authentication are respected.
In a common system (development) life cycle model multiple environments are present to support taking a change from development to production. In this common practice, making changes or new development that is then tested before pushed to production ensures a safe and controlled deployment procedure.
In Canvas, we have a similar environment setup with beta and test (for some). However, the environment behavior in Canvas is quite different from what would be expected. For example, the beta environment is every week overwritten (“refreshed”) with the content and configuration of the production environment. The same apply for the test environment but with a longer frequency, every third week.
The existing setup in Canvas where beta and test is overwritten with production content and configuration causes us issues in our development/change process. We constantly must reconfigure global settings and re-import our developer accounts after a environment refresh.
In our Canvas setup we have a discovery page for our production environment (discoverypage-prod.ourdomain.com) and a separate Discovery Page for our beta environment (discoverypage-beta.ourdomain.com). Users navigating to our production Canvas instance (company.instructure.com) are redirected to our production discovery page, if not already authenticated, where they can choose authentication method.
Having a discovery page per environment allows us to perform changes and tests in a controlled fashion before they are pushed to production. A issue we are facing is when the beta or test environments are refreshed with production and our authentication settings are overwritten resulting in users navigating to company.beta.instrcuture.com being redirected to the production discovery page and then signed in to the production instance. The user, unaware they are in the production instance, can then unintentionally do changes on production content!
Another issue we face is with our developers, an external partner to us, who is building an integration engine for some data sources between Canvas and our ERP system. They are using our test environment for the development work and every third week, timely enough for the sprint UAT, they suddenly cannot access the test environment due to the refresh where the authentication settings have been overwritten and their user accounts been dropped.
With the above issue description we would like to suggest an idea where an administrator can control what is pushed and overwritten from production to beta and test. For example we would via some configuration be able to define that e.g. Authentication settings shall be respected and not overwritten during a refresh. The same for accounts where it would be preferred to be able to decide if accounts are overwritten/dropped.
I also support this existing idea suggestion to have different icons for the different environments.