In 2019, Canvas teams are researching an adjustment to the Canvas release schedule focusing on two key objectives: make new features more predictable and improve the quality of Canvas code. We hope you will consider these thoughts with us and provide your feedback!
Let’s start with the status quo—we know that three-week releases are fast. Canvas loves agile development because it helps our teams move faster and brings features more quickly—more and more software companies are moving to cloud-based continual deployments because of both the engineering and customer benefits. Visit any Instructure office and our teams may seem calm and content (and quiet!) working away on their computers, but if you could peer inside our network of Slack chat channels, you’d find the constant chatter among developers and QA and product teams reviewing changes, brainstorming code workflows, checking the status of outstanding tickets, and providing good-natured banter (my favorite part, really).
Canvas Code Quality Improvements
Our three-week releases include code deploys for predetermined features, fixed bugs, backend changes, performance updates, API modifications, platform upgrades, and other code adjustments completed by our engineering teams. All of our changes are code reviewed and tested by our Software Engineers and Software Engineers in Test to ensure it meets our (and your!) standards. These practices allow us to prepare and deliver new Canvas code in remarkably short cycles.
Releases and deploys don’t have to be synonymous terms—in fact, our teams would prefer that they weren’t. What if we could put all this code into smaller deploys so teams can focus better and fix bugs even faster? What if you had more time to prepare for feature updates? These are the questions we want to answer, and these results can be done without adversely affecting you as the customer.
Predictable Feature Changes
From the customer standpoint, we know that three-week releases include a lot of content that may not pertain to your user role. Or, you’re an admin who gets overwhelmed at the idea of training your entire institution about all the upcoming changes. We’ve been working hard to ensure our release notes give you more tools to help you be the superhero you are, and our new proposal would also give you more time to do just that—we want to ensure consistency on your side so you know exactly when a release is happening and when, without having to consult a calendar.
From Instructure’s side, we want to be more mindful about what changes impact your experience, not simply focusing on changes in the interface. We realize there are plenty of behind-the-scenes adjustments that may affect Canvas behavior, and to improve your experience with Canvas features, we want to improve how we release these changes to you.
Canvas Release Proposal
Current Release Cycle
The current release cycle includes the following 3-week structure:
- All new code is deployed to the beta environment with the scheduled beta release (week 1)
- Canvas release notes are published in advance of the production release (week 2)
- All beta environment code is deployed to the production environment with the scheduled release (week 3)
To clarify terminology, a deploy means making code available in a specific environment; code may or may not be visible. A release represents a scheduled event when code is intended to be visible. Currently, deploys and releases are treated as the same thing.
Proposed Release Cycle
To be more mindful with what code we release and when, the proposed change includes a monthly feature release overarching two-week code deploys.
New features are defined as any changes that change user workflow for any Canvas-related product. Some new features may be managed by Canvas admins or instructors as a feature option in account and/or course settings. Other features may come from fixed bugs that require a workflow change or an interface change, or API/SIS integration adjustments. The Canvas product team can directly control these features for all products and manage when they should best be released. Feature releases would still follow the regular process of releasing to the beta environment, followed by the production environment.
Non-features are defined as non-customer-affecting backend changes, code for new projects, fixed bugs—basically any code that does not affect any Canvas workflows or functionality, or code that improves unintentional behaviors. Two-week deploys allow engineering teams to verify less code at one time, improve quality, and fix bugs twice as fast. Deploys still follow the regular process of deploying to the beta environment, followed by the production environment.
The proposed schedule is as follows:
- Non-feature code is deployed to the beta environment and then to the production environment two weeks later; public-facing deploy notes (such as fixed bugs) are published the same day as the production deploy
- New features are released to the beta environment a month before the production environment release to allow advanced planning
- New feature release notes are published three weeks in advance of the production release
- New features are released to the production environment on the first Saturday of every month; the Test environment is also refreshed to match production data
Proposed Implementation Timeline
Our teams are excited to consider these changes, and we hope you are, too! But rest assured, these changes will not be implemented until all aspects have been thoroughly reviewed. And because we’re aiming to minimize disruption, we’ll make the release cycle change when we feel the change is best suited for you as well. Our approximate timeline looks like this (and is subject to change):
- November 2018: Publish Canvas proposal
- December–January 2019: Review and explore needs for engineering process changes
- February–May 2019: Implement engineering changes
- June/July 2019: Implement new release cycle process
We look forward to your feedback!