My new WordPress build process – Lando, CircleCI, and Pantheon Multidev
Dependency management remains one of the thorniest problems in web development. Consider the typical WordPress stack, which as a codebase may only contain about 5% proprietary code, the rest being libraries, plugins, or other open source projects.
Should we check those dependencies into version control? Oh hell no! Brevity, brevity, brevity, my friends. Same as in code as in prose or poetry.
I rely on Pantheon for my WordPress hosting. They are a very good company and I enthusiastically recommend their services. One downside to the Pantheon platform is the lack of support for git submodules, which would be my preferred method of handling dependencies. C’est la vie. For a while, I thought that I’d use DeployBot to handle this task of dependency compilation. But between the cost, the acquisition, and the lack of a true CI environment, I ended up cancelling that service in favor of using CircleCI for all my CI/CD needs.
I digress! The real reason for the season, er, blog post is sharing my experience with composer workflow on Pantheon. There’s some composer fundamentals here, but the gist is that composer (the PHP package manager) can embiggen the repository during the continuous integration workflow. That way, we can deploy the so-called “fat” repository to Pantheon, without checking all the dependencies into version control as individual files.
My setup is based on Pantheon’s demo WordPress with Composer repo. I wanted to share a few tweaks.
- For the past month I’ve been using Lando for local development. Lando grew out of the Kalabox project, and it’s particularly good at replicating Pantheon environments on your local computer. I’m even using Lando in CI to standup a fully functional site for behavioral and integration tests (including Node Apps used to power public URL). Here’s a peek at Lando config, featuring my custom build step for the appserver and an additional Node app.
And here’s what that looks like in the Circle config.
Note that my test step and deploy step use different CircleCI environments. For Lando, we need the classic machine context; for deployment, we can use a Docker image. Above I’m using a Drupal docker image (as in the Pantheon tutorial); could probably switch this to a smaller image but just wasn’t worthwhile yet.Note also that I had to extend the no output timeout for the Pantheon deployment step.
- I had to create an SSH key on my local computer and then associate the private key to CircleCI and the public key to Pantheon. This prevents you from seeing a message like this in the workflow.
- A lot of the value from this workflow depends on Pantheon’s Multidev feature, which allows multiple environments to be created based on the main ‘dev’ environment. I had thought that the pay-to-play on this feature was $400/mo through Pantheon for Agencies or a Business plan. But! I was wrong! Pantheon has recently (quietly?) open this feature up to all agencies, with no payment needed. Just head here, sign in, and you’ll be on your way to a glorious pull request/ephemeral environment workflow.
- I had some back and forth with Pantheon engineer Greg Anderson, who was really reluctant to encourage a “direct to dev” workflow where a commit to master gets pushed directly to the dev environment. We disagreed at first on the utility of this path; I feel it’s important to support emergency commits but building that path would possibly make the build tools plugin harder to maintain. So in my opinion/analysis of the code, the Pantheon workflow would break if someone committed directly to master. But there’s an easy answer; to mitigate this risk, we can add some branch-specific protections to the repo:
- My uploads folder got committed to the repo somehow, and removing it from the git cache ended up being a PITA.
This turned out to be the fault of my copy-pasting from the source repo; the .gitignore put together by Pantheon gets split in half based on whether the files should be ignored in Pantheon version control.