Managing multiple websites

• Drupal, Backdrop, WordPress, static sites; some folks at agencies,

some folks solo, some folks at larger orgs

• Previous experience: at an agency, did builds and support contracts;

now inhouse at a nonprofit org, managing 10 WordPress multisite networks, 10-200 sites on each.

• "Short stack developer" -- learns to do a little bit of everything out

of necessity, but not architecting software

• Using WPEngine for hosting; a few people use it. Some folks also use

Pantheon and Platform.sh (the latter gives most flexibility).

• Components of managing websites: hosting, domain name/DNS, maintenance

& updates, backups, content delivery networks (CDNs), SMTP/email, monitoring

• One person manages actual hardware, a whole rack of servers; also

develops websites, uses git for workflow

• Websites you didn't build are harder to maintain
• WP multisite: when you log into WPEngine dashboard, go into each

install and run the updates. Another too, WPMudev, plugin suite and dashboard for managing multiple WP installs, gives you one button, updates all live sites directly (!)

• WP recently added an auto-update feature; enabling it is creating a

security hole in the system.

• Need to weigh risks: staying up to date by making the code writable by

the web process, escalating

• When to apply updates? Only when they apply to you? Some people do

core updates immediately, contrib updates quarterly

• Support = client requests, supporting, development etc. Runs gamut

from super functional "let's keep site secure."

• Write down a standard operating procedure for running updates
• Use Teamwork as a ticketing system for both professional

services/project management.

• Another shop: Jira for agency work, ZenDesk for support side of

things. They're a bit more integrated now, things that synthesize stuff, bring stuff from Jira to ZenDesk. Looked at ServiceDesk a while back; no clear way to escalate things from that to Jira.

• Need tools to help manage, organize, escalate.
• Train clients on how to use the ticketing systems, how to submit good

tickets.

• Monitoring
  • New Relic (they come with Pantheon accounts): runtime, performance

monitoring, slow queries, etc. But your hosting platform has to have it built in. There's a free version but it's really hard to set up.

• • Monit -- open source
  • Nagios/Icinga
• Documentation
  • Looking for a ticketing system that allows someone to take a ticket,

scrub it, turn it into a knowledge base/FAQ thing.

• • Having documentation per site--quirks, customizations, the things

that make the site special/funky.

• • Inheriting sites that aren't well documented, eek.
  • Checklist: baseline checks for sites that are being inherited so they

know where they're starting from.

• Nice having standardization across the board for all managed Websites
• Maintaining themes and plugins across websites: GitHub Theme Plugin

Updater, allows you in styles.css to specify the GitHub/BitBucket/etc URL for your theme; if you commit a change and up the version number on your theme, your site gets notified, you can roll things out more easily.

• Drush, wp-cli, cv for CiviCRM -- all the command-line tools can really

speed things up

• You can automate testing, but it's impossible to have complete

coverage. Time and money make it impossible. Also multiplicity--so many websites to be testing.

• Swiss cheese model of testing: each piece of cheese has holes, but if

you pile up the different tests you cover all the holes.

• Use a lot of Pantheon's new multi-dev stuff, have everything go

through pull requests.

• Testing
  • Favorite clients are the ones willing to do their own QA; they know

the most important things that they need to test.

• • Very hard to deliver full testing for every little thing
  • Codacy: checks for best practices in coding standards in Drupal
  • Peer review is also important!
  • Civi puts out release candidates out; they need testing. They know

some shops have some tests; theory is that there's a lot of coverage out there, just not coordinated enough. How do we coordinate channels so all the testing gets done before the release is deployed.

• • Selenium
• Reporting protocol or reporting tools -- give ways for people to come

back with their feedback

• Backdrop runs tests on every release, but there's some stuff that

slips through cracks or just isn't tested

• Backdrop has developer check-ins every two weeks, also have open QA

time, office hours. Chat channel that anyone can join.

• Can't incorporate Behat tests into the infrastructure.
• Panopoly has a lot of tests built in.
• Back in the day used something called Foreman, any time an app was

fired up it would record the OS, report any kind of bugs that happened; error reporting; you get info about the issues that have happened with OS/browser specific info.

• Humans are the variable, even if there are systems in place. How do

you help people avoid the problems?

• "Take small bites" to get to a better place with the managing,

maintenance, support.

• Different models for different sites: some sites need updates

immediately, some people

• Lower requirements for documentation: choose a level of documentation

that you can consistently meet, start there, get it into your workflow.

• Consolidate your documentation!
• Write inline documentation in your own code!
• How do you keep track of all the clients' accounts/info? How do you

have your own access to those accounts.

• • Lots of folks say: get the client to set up those accounts using

their own email addresses, share account access with you securely, they stay in control of the account.

• • Folks are using LastPass and similar to keep track of that
  • Standardize how accounts are created, named, tracked.
• DNS/domain names:
  • Use Namecheap, they're less evil, but now have access to TONS of

Namecheap accounts.

• • Make sure clients handle their domains directly!