Deployment and DevOps: Standard WordPress Process
For most of our WordPress sites, we use CI (continuous integration) to be able to update or deploy new versions. Most WPEngine hosted sites we maintain have two or three environments. The first, live environments, host the code that creates the version of the site seen publicly. The second and third, dev and staging, are versions of the site that allow presentation of in-development ideas before sending them to a public environment.
To get any update to any of these environments, a developer must use either a CI process that automatically deploys, or update the site via pushing the code manually (we shouldn't encourage doing this often as repeatedly manually deploying sites can lead to bloating budgets in processes that can be automated).
The average WordPress CI process works as follows: all of our code is stored in Github repositories, these repos are equipped with pipelines in the form of either Circle CI actions or Github Actions. When a developer pushes code to specific branches of a repo (main or master branch for live, staging or development branches for their respective environments) these actions trigger, compiling the site. Once the site is compiled within the action, it is synced with the WPEngine environment. For the most part, if configured correctly, the developer creating the site shouldn't have to think about this process whenever they want to update the site.
Github
Hosts our repos and is where our code review and collaborative iteration process takes place.
Github Actions
The second option for our "CI Pipeline", Github Actions currently provides the easiest to integrate CI for our needs. Many of our projects utilize these pipelines since we no longer have to maintain external pipelines and can combine accounts.
Like in the case with Circle CI, Github Actions listen for code changes in specific branches and deploy to related environments when changes are merged.
Circle CI
In April of 2023, Kalamuna started migrating away from using CircleCI in favor of GitHub Actions for WordPress clients. Circle is where we used to host the majority of our integration processes. We've since moved a lot of projects to Github Actions and most new sites are equipped with Github Actions scripts instead by default.
Most projects hosted there require a developer to be "subscribed" to the pipeline for it to run, not to mention for updates and failure notifications. So older projects may need to have someone resubscribe to ensure the build takes place.
WPEngine
WPEngine hosts the majority of the compiled code that we produce. In the average project case, either Circle CI or Github Actions will automatically sync code changes made in the Github repo to environments hosted here.
WPEngine also covers a wide number of features relevant to the regular hosting of our WordPress practice, like taking regular backups and automatic updates. As such, the code synced to the WPEngine instance is often only the /wp-content/ folder such that WPEngine can maintain its own dependencies, version of WordPress, and uploads.
Multi-Dev Branch Testing and QA
Some WordPress hosting platforms limit the amount of environments you can set up for having clients test new features (like WPEngine). In this case, we can set up a free Pantheon Sandbox, and migrate the content over to it for the client to test on an environment outside of their main hosting platform. This is for cases where we cannot use the DEV branch/environment for testing larger feature changes.
To create a copy of the WPEngine site on Pantheon…
Create a Sandbox site on Pantheon
Grab a database backup from WPEngine
Upload the database backup to Pantheon
Use git to push the code from WPEngine to Pantheon
Download the uploads folder from WPEngine via a backup
Upload the files to Pantheon via https://docs.pantheon.io/guides/drupal-hosted-btworkflow/upload-files with either SFTP or
terminus rsyncYou now have a development site!
An alternative solution to this is Tugboat, but it costs money, and is not quite that stable.