UPDATE: Change Management for Websites is now live on the platform.
There's a major innovation on its way to the Pantheon dashboard. Starting soon you'll see the familiar version-control-powered Code Log on the Test and Live environments replaced by a much more useful Deploy Log:
What is "Change Management" and why does it matter for Websites?
Ever since we released Multidev, dev team leaders, shop owners, and prospective Enterprise customers have been asking us when we would have permissions on our dashboard. It's a natural follow-on thought: once you have the ability to create specific environments for development, you may then want to limit access to production.
There are plenty of reasons to want this: bringing in junior team members or trainees who might make a rookie mistake, sharing work across different teams, using contractors, or honoring internal policies around how and when releases happen. The more I talked to customers, the clearer it became that the primary value was in protecting the production environment, with tracking changes as a close second.
There's actually a whole discipline in the IT and organizational theory worlds that goes back decades called Change Management. It's a broad a set of practices designed to help complex organizations make changes to complex projects—e.g., a web team working on a CMS-powered website—while minimizing risk, eliminating unexpected side effects, and maintaining clear and effective communication.
That's what we're delivering. Pantheon gives teams, agencies, companies, and organizations the ability to enjoy all the benefits of Change Management for Websites. Getting that value actually requires multiple features:
The Deploy Log
As per the intro, we've augmented the low-level code log (a list of the git commits made by developers) with a Deploy Log in the Test and Live environments. Any time you deploy, you'll have an opportunity to add a meaningful message about what's going out:
A deploy message has a lot of value. Individual commits are often super-granular in scope, and developers are notorious for being terse in their commit messages. The act of doing a deploy is more measured, and focused on the value at the end of the rainbow. Deploy messages can be more rich, might link out to external documentation (or reference bug/story tickets), and are often written by a project manager or senior developer.
Tracking deployments explicitly is a core improvement to bring better clarity for team members (not to mention Pantheon's Customer Success Engineers) as to what's been happening with a site. While the list of commits is nice, and still available, seeing the commit timestamp of when a change was made on a developer's local environment tells you nothing about when that change went live.
We're pretty confident that everyone on the platform will benefit from the Deploy Log.
Controlling Deployments with Roles
The complement to the Deploy Log is a system to allow site owners and admins to determine which team members should be granted access to deploy. We spent quite a while thinking through the requirements here—speaking with customers and delving into our own experience—in an effort to deliver maximum value with minimum hasssle.
Complex permissioning matrices are where good products go to die, and we had no desire to implement something that mirrored Drupal's user access checkbox grid, which I consider a usability anti-pattern. Unnecessary complexity is bad, but in a security-related product it's more than bad: it's dangerous. Accidental misconfiguration is a real risk. The whole point of Change Management is improving coordination and minimizing honest mistakes, and it would be a real fail if we found out we needed Change Management for Change Management for Websites.
Instead, we have a simple set of capabilities that admins can grant to develop or deploy. These features are managed through the Developer Dashboard, a console for site management on the platform. The capabilities can be set at a default within the organization, as well as being granted, escalated, or downgraded for a particular site if necessary.
This follows our philosophy of having "an opinionated product". We've analyzed the needs of our users and come up with a solution that should work very well, as well as being totally bulletproof. If you would like to learn more, get in touch or watch the webinar recording about Change Management for Websites.Topics: Development, Security