Shipping changes to enterprise customers requires some extra due-diligence. Millions of users rely on Chromium tech to do their job. For home use, we strive to make the browser as simple and safe as we can, by taking complex configurations off people's minds. However, in small and large enterprises, this is a task left to specialists who need their browsers and OSes to fit perfectly in the complex puzzle of hardware and software that drives their org. Enterprise customers: Have complex and unique environments, supporting a wide range of apps and use cases for their users Take time to adapt to changes, which may include testing and training Incur large costs because of disruptive changes
Even changes that are not targeted for enterprises may still have an effect on them. (Non-exhaustive) examples: Major UI changes Changes that affect how the browser interacts with proxies, firewalls, certificates, network protocols, and common enterprise configurations (including adding new network endpoints that must be whitelisted in enterprise firewalls) Changes that interact with policies, like changing default values Changes to web technologies and implementation of specs, especially interventions (example) and deprecations
Any change that's likely to affect enterprises should follow these guidelines, easing the burden for IT admins managing their fleets, and reducing the number of changes that need to be reverted from the stable channel (see bugs from m69, m68. m66 for recent examples). How to ship enterprise-friendly changes1. Provide advance noticeDescribe your planned changes by joining and emailing the chromium-enterprise technical discussion group. Announce changes as early as possible, minimum 3 milestones (~4 months) prior to launch to stable, and sooner than that for highly disruptive changes. Additional communication channels may be used, but at a minimum, include the announcement in the "Coming Soon" section of the enterprise release notes. This can be done by messaging the chromium-enterprise technical discussion group. Include: What is changing Why it's changing When it's expected to ship to stable Does this need admin console support or client side only? What enterprise admins and/or users will have to do in response
Continue adding the reminder to the "Coming Soon" section of the enterprise release notes in subsequent releases until the feature is shipped.
2. Include a temporary policy escape hatchWhere possible, include a policy to toggle the change on and off. Ship the change to stable with the policy Despite best efforts in providing advance notice, most customers get broken here. This is why it's critical to include the policy to revert the change. This gives enterprise customers time to adapt, without keeping them on an old version
In the enterprise release notes, include: What is changing When it's expected to ship to stable Why it's changing Path to admin console setting (if applicable) What enterprise admins and/or users will have to do in response Include a link to the policy which will revert the change back to the old behavior. Tell users how long the policy will be available (2 - 4 milestones for changes that are easy to adapt to, 4 - 8 milestones for changes that are difficult to adapt to)
3. Remove the escape hatch policy as per timelineRemove the flag and the policy that revert to the old behavior, consistent with the release notes when the change was shipped In rare cases, the escape hatch may be permanent and this step is omitted
|
|
