Trellis / WordPress / Plugin Upgrade Automation

Hi folks,

Our agency has over 100 websites based on Trellis and hosted on DigitalOcean. We’re consistently running into a situation where we want each new website to be on the latest version of Trellis (for a number of reasons).

We run into issues where clients will come back to us for website updates and we’ll have to clone down an older Trellis site that has a bunch of differences from the newest version of Trellis. Our take has been to upgrade these websites manually by cloning down the newest version of Trellis and then manually pull all plugins, uploads, etc over to the new Trellis build.

We also typically upgrade to the newest version of WordPress and upgrade all plugins to the newest versions at this time.

Lastly, we create a new DO Droplet, reprovision, deploy and then update the DNS for each of these sites.

In summary, there’s a lot of manual maintenance involved here with maintaining Trellis sites long-term and we’re looking to write a script that will automate all of this for us. Below you will find our objectives that we’re looking to accomplish in a PHP Script (please let us know if we should not use PHP). I’m hoping that the community can provide us with feedback on any of the things that we are going to be attempting to accomplish.

Additionally, we haven’t yet selected a developer to build this for us, so if you’re interested in being hired to do so, please let me know. We’re planning on opensourcing this entire thing once it’s built.

Maintaining and Updating WordPress/Trellis Sites

Upgrade Trellis

  • Git pull of existing private repp
  • Create a .zip backup of the current production files and database (stored on Digitalocean Spaces)
  • Pull all images from Production
  • Update the WordPress YMLs with the necessary settings (automatically copying over anything that seems necessary)
  • Need to look at other deploy script sections in “trellis” directory in old project and copy over any custom stuff to the new one, This would have to be flagged and then manually migrated in these instances. The flagged sites should create a ticket in Jira.

Update WordPress and all plugins

  • Spin-up a local instance using the new dev YML? (vagrant up)
  • Vagrant SSH into the machine and run WP-CLI to:
  • Update WordPress and all plugins
    • Detect any errors that have been thrown for all pages (by parsing the sitemap.xml pages)
    • Attempt to resolve these automatically if they are deprecated functions - by replacing those instances of code with the updated/compliant functions. We’re assuming that this will require a decent amount of trial and error and will result in a library of conditions that might be able to be checked against. From there, we will, when receiving an error on upgrade, check this library for an automated resolution.
    • If an automated resolution isn’t possible, a ticket will be created in Jira with the project name, and error message.

Update Production

  • DO Snapshot old server
  • Database dump
  • Put current website in offline mode (in whatever way is best to handle this)
  • Update production server to the newest compatible version of Ubuntu
  • Clean server contents back to that of a fresh Droplet (we don’t want to create a new Droplet as this will require the DNS to be updated to a new IP address. We don’t want this because we don’t always manage the DNS ourselves and our clients would have to update this IP – removing the ability for us to automate this entire process)
  • Provision server
  • Commit & Deploy
  • SCP/rsync all images
  • Import database dump

Looking for general feedback on whether or not:

  • This is possible
  • We’re missing something
  • There’s a better (or existing) way to approach this
  • You’re a developer that’s interesting in being paid to build this.
1 Like

We use dependabot to update composer and yarn dependencies plus CircleCI to deploy.

Auto update Bedrock & Sage dependencies (including plugins)

  1. Dependabot creates new pull requests for every outdated dependency
  2. Pull requests trigger CircleCI build (percy, codeception, phpcs, etc)
  3. If the build passes, dependabot auto-merges the PR into master
  4. Whenever master is being pushed, CircleCI deploys to remote servers

How about merging Trellis & Bedrock & Sage patches?

We do it manually because we have no good soluton to auto resolve merge conflicts.
If you keep roots’ git history, it shouldn’t be too much trouble. (but still time comsuming)

How about provisioning remote servers?

Auto reprovisioning remote servers is too dangerous for me.
In fact, we avoid provisioning servers and use a managed hosting instead.

we’re looking to write a script that will automate all of this for us. Below you will find our objectives that we’re looking to accomplish in a PHP Script (please let us know if we should not use PHP).

Have you tried GitHub - roots/trellis-cli: A CLI to manage Trellis projects ?

  • Pull all images from Production
  • SCP/rsync all images

Do you mean downloading /app/uploads?
If yes, store them on S3 (or similar) would make your life easier.

See:

Questions:

  • How do you handle backups? (anything else besides DO snapshot)
  • How do you restore form backups?
  • How do you monitor uptime?
  • How do you monitor server stats (CPU usage, RAM usage, etc)?
4 Likes

I’m interested why you don’t use a multisite in this instance? This way you only have to maintain one infrastructure - granted with a single point of failure but it could probably save you a heck of a lot of time, and allow you to invest in one stack instead of dilute your efforts across many

Im actually looking for a full time role or contract work (UK), so if this is pressing feel free to reach out

Please don’t use PHP. Use bash if you can’t do it with Ansible or Ruby and into Trellis.

@TangRufus response’s pretty accurate to a semi-automated workflow you can integrate into Jira sprints easily, but it’s focused on teams with a single project.

There are actually 3 different types of Stack setups I used:

  • Standalone Stack (Trellis & Bedrock default)
  • Multisite Stack (Trellis & Bedrock default in multisite)
  • Shared Stack (Trellis & Multiple Bedrocks)

The Shared Stack feels like the right choice, but in matters of stack maintenance, server performance and server resources, is better to multisite IMHO.

BTW I’m a freelance DEV looking for remote work.
Drop me a line if interested! I’ve some own tools already built. :slight_smile:

Best!

1 Like

There is also an OpenSource, self-hostable tool that supports composer files:


I plan to use renovate with Jenkins CI.

And a feature request for composer…

This topic was automatically closed after 42 days. New replies are no longer allowed.