I inherited responsibility for a handful of small client sites. One is plain PHP, another WordPress, another a JavaScript build that needs several packages updated before it will run locally. None is huge, but remembering their individual deployment quirks is getting ridiculous. I'm considering a one-page maintenance note per site: runtime version, repository, deploy steps, backups and known fragile bits. What else would you document first so the next person isn't reverse-engineering the project from scratch?
Keeping client sites maintainable when each uses a different stack
- webdev
- keeping
- client
- sites
31
0 replies
I’d put the update process in plain language too, not just tool names. ‘Run this command, wait for build, then clear cache’ is worth more th...
I’d put the update process in plain language too, not just tool names. ‘Run this command, wait for build, then clear cache’ is worth more than a folder full of links.
2 replies
I’d add the boring stuff people always forget: where backups live, who has access, and what breaks first when you update dependencies. The m...
I’d add the boring stuff people always forget: where backups live, who has access, and what breaks first when you update dependencies. The maintenance note is most useful when it answers ‘what will hurt if I touch this?’
Deployment quirks are huge. I’d also note any environment variables or secret-handling oddities, because those are the things that make a site look fine in one place and completely dead in another.
And record the last known good deploy date. If you inherit a site and something goes sideways, that little breadcrumb can save a ridiculous...