Canvas Deploy FAQ

Document created by Erin Hallmark Administrator on Jul 30, 2019Last modified by Erin Hallmark Administrator on Oct 29, 2019
Version 5Show Document
  • View in full screen mode

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.

 

Deploy notes are not meant to be an exhaustive list of all fixed behaviors. Customers with a greater interest in the full deploy can access our open-sourced canvas-lms Github repository deploy list. If you aren't familiar with GitHub, see our Canvas LMS Github Repository Tutorial to get you started.

 

Deploy notes will eventually become more automated and transition from their current format. More information will be posted when made available.

 

How do you define the entries highlighted in deploy notes?

Most commonly, entries will only include fixed bugs that have received a notable number of support cases. 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 follow deploy notes?

If you're already following the Canvas LMS Release Notes space, you'll also be notified when deploy notes are posted. For help following the space, see How do I follow people, places, or content in the Canvas Community?  You can also customize your activity stream via How do I create and manage a custom activity stream for following content in the Canvas Community?  

4 people found this helpful

Attachments

    Outcomes