Showing results for 
Search instead for 
Did you mean: 

Canvas Deploy FAQ

Canvas Deploy FAQ

What is a deploy?

A deploy occurs when new code is placed in a specific environment. Deploys take place every two weeks.

What do Canvas deploys contain and not contain?

Deployed code may or may not be visible, but it is code that does not change customer workflows.

Canvas deploys contain code changes that are intended to fix bugs, clarify interface wording, improve performance, and prepare for new features. We know through experience that smaller, more frequent deploys leads to a higher quality product. And when there are problems, our teams can fix them faster.

What can you tell me about the impact of deploying on a weekday?

Our overall deploy process has matured enough to move the primary Canvas deploys to a weekday. Deploys of supporting Canvas services are and will continue to be deployed even more frequently. To ensure that deploys are non-disruptive to customers, our teams have been planning and are already implementing several new safety precautions, including tightening our processes on how we characterize a change in Canvas (e.g. feature vs bug).

Should deploys affect my institution?

Code included in deploys should not affect customers aversely. As always, customers should experience no downtime as with the current deploy process.

However, note that the majority of Canvas deploys include code for future functionality and infrastructure improvements.

  • Institutions that rely on custom workflows such as JavaScript/CSS applications should continuously review the functionality in the Beta environment for potential customization conflicts.
  • Institutions using unsupported browsers, most notably enterprise extended releases, may be affected. Consider maintaining the most recent browser release to ensure the best Canvas user experience.

How does the deploy process work?

The new process will slightly modify this behavior, though releases and deploys have been separated to emphasize their purpose. Releases are to identify expected changes to Canvas—and allow customers to prepare for those changes in advance—while deploys are primarily for code maintenance.

All customer accounts will receive the code from the deploy in a scheduled progressive rollout window. Deployed code is deliberately monitored to ensure quality. Any behaviors that need to be addressed are either reversed or corrected before resuming the rollout.

  • The rollout window originates from Instructure headquarters in Salt Lake City and takes place between 9am Tuesday through 4pm Wednesday US Mountain time.
  • To convert the rollout window to local time, see the Instructure Time Zone Communications‌ document.

Customers will not specifically be notified when their Canvas account receives the deploy during the deploy window. Any unintended behaviors noted by an institution should be treated as part of that institution’s support protocol. However, code may be deployed outside the scheduled deployment window at any time. Primary use cases include correcting adverse Canvas behaviors or rectifying security concerns. All deploys and included commits can be viewed via the canvas-lms Github repository.

Are bug fixes always part of deploys?

Changes characterized as a bug fix can be deployed to the production environment at any time. Our tightened processes ensure that bug fixes are only restoring intended behavior. 

If a bug needs to be addressed by adjusting functionality or the user interface flow, the bug will be changed to a feature-type categorization and available as part of the upcoming month’s release with other new and updated functionality.

Do deploys place more focus on fixing bugs?

Quicker deploys will allow our teams to be able to fix bugs more timely. Bugs are prioritized as part of each planning meeting depending on severity. We obviously do not want to release features or changes prematurely and we anticipate that this new process will also help us improve our quality in our feature deliveries.

Do you publish deploy notes?

Initial entries for the main Canvas deploy will be available as deploy notes the day following the beta deploy in the Canvas Release Notes space (Deploy Notes page) as its own document. However, because engineering is creating smaller teams with quicker releases, up-to-date deploy notes are difficult to maintain—as well as customers to reference. Any additions to the deploy that may be a risk to customers will be added to the deploy notes as quickly as possible before the production deploy. Ensure you are following the release notes space to receive notifications of all updates within the space.

All code changes can be reviewed in the automated Canvas Deploy Source Code Summary link included in every deploy notes document (beginning with the 2020-04-04 release).

Additionally, customers with a greater interest in the full deploy summary can access our open-sourced canvas-lms Github repository. Customers can also customize code searches in GitHub. More details about using Github is available in the Canvas LMS Github Repository Tutorial.

How do you define the fixed bugs highlighted in deploy notes?

Most commonly, entries will only include fixed bugs that are noted by our Canvas support team in our Canvas Current Issues, or behaviors that affect a significant amount of Canvas users. Not all cases will be included in deploy notes. Any customers who are truly concerned about the status of a bug should have reported it as a support case and will receive an update from support when it is corrected.

How do I subscribe to deploy notes?

If you're already subscribed to the Canvas Release Resources page, you'll also be notified when deploy notes are posted. For help subscribing to that page or this document, see FAQ: Subscriptions.

Labels (1)
Tags (1)
Version history
Revision #:
3 of 3
Last update:
‎08-11-2020 08:37 AM
Updated by: