/ Project Handbook

Working with Live Sites, Subscribers, and Customer Data


As our number of live sites grows, our projects become more complex, and we work with more high-profile customer data, the importance of working error-free and with high precision is crucial.

Working on the Special Projects Team involves high trust, and we rely on the diligence of everyone involved on a site to work with the utmost caution and care. This page is not a comprehensive guide to answer all questions but outlines some critical aspects and guardrails when working with live sites, subscribers, and customer data.

See also “ground rules” to share with third-parties who have access to our partners’ live sites ↓

Communicate to the partner

Consider whether the partner is aware that changes may be taking place on their live site. Particularly in situations where we’re being proactive and not responding to a specific incident, ensure that the partner is aware their live site is being manipulated by our team.

Do not rush

For every action we perform on a live site or when working with live or customer data, we must take the time to do multiple checks and be totally sure before clicking, migrating, pushing, publishing, merging, or actioning anything.

We move fast, and timelines can be tight, but if you need more time to check your work or a setup properly or are uncertain about any implications, it is your responsibility to flag that.

Understand the setup

For every site you work on, you are expected to thoroughly understand the setup before performing any action. What happens if I commit to trunk? What branch is connected to what site? Is the site linked to a social account? Does it have any subscribers? Are there any marketing tools connected? Are there any members/users on the site? What happens if I clone this site?

This is not a comprehensive list of things to check, and if you are unsure, take the time to ask or verify your assumptions.

Buddy check

If you know you’re working on a site that has subscribers, WooCommerce, marketing tools, memberships, or any form of connected or custom user data, you should do a buddy check before proceeding with any action that can trigger notifications, renewals, emails, SMS, or subscriber or customer messaging. 

Write up the steps you plan to perform in Slack, P2, Linear, or GitHub, and get someone to take a look at it. If you are the person being asked to buddy check, and you need clarification on any of the steps involved, reach out to others to get clarity.

In any situation where there’s a remote chance we could trigger any form of mass (or contained) messaging, two people should be fully informed and in agreement before proceeding.

Customer data

When working with our partners’ data, like customers or subscribers, they put an immense amount of trust in our hands. We need to recognize that small actions we perform with their data can have a massive impact on our partners and in turn their trust in us as experts.

When working on tooling, imports, or development sites that hold our partners’ customer data, always work with scrambled or obscured data until everything has been tested and you’re ready to complete the final migration, import, or launch.

Imports

Always use obscured or scrambled data when doing imports of any kind and while you build out your tooling. When you are ready to do a final live migration or import, start with data containing your personal email address or phone number, or subscribe to the site to ensure no messages or notifications go out. Ensure WP_IMPORTING is set for any custom imports or migrations.

Do imports using the principle of 1-2-10, starting with one row of data, evaluating, continuing with two rows of data, evaluating, and so forth.

Consider a peer review system for high-stakes imports to mitigate any unforeseen events or edge cases. 

Safety Net

Install Safety Net everywhere except live sites—local sites, development sites, issue-specific temporary sites, etc. Do not skip this step. If you need to test functionality that Safety Net is blocking, rely on logs for as much as possible.

Predef “ground rules” to share with third-parties who have access to our partners’ live sites

On occasion, our team will work with third-parties who have access to our partners’ live sites (███████████████). These folks may not be developers, but for a valid reason they have access to the site – introducing a level of risk. We’ve created a brief TL;DR: of this page to share with them as early as possible to ensure we’re all aligned on how to treat our partners’ live sites.

The partners of Automattic’s Special Projects team have high trust in us and we rely on the diligence of everyone involved with a site to work with the utmost caution and care. Therefore, we have a few guidelines we would like you to be aware of:

  • Approval before changes: do not make any changes on a partner’s live site without prior permission from our team.
  • Staging site usage: use our partner’s staging site to test any changes or updates before proposing to make those edits on the live site.
  • Safety Net info: our team’s Safety Net plugin is installed on all staging sites. If you have any questions about its use, please let us know.
  • Access control: limit access to the live site to only those individuals who have been explicitly authorized by our team.

Please reach out with any questions or concerns about the above.