Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

Circle CI

One option for the "CI Pipeline", 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 (or should be, as of 14/11/2022 KPPro doesn’t seem to use GA).

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.

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.

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.

  • No labels