Code that is committed to the deploying branch of a WordPress environment should contain all needed assets. On deploy, no additional building is done except for submodule includes. When using composer, for example, code should be committed to a branch only after running
composer install. An alternative to this is to set up a continuous integration and deployment (CI/CD) method.
For branches already set up with continuous integration and deployment (CI/CD) (
-built branches), merged changes to a
develop branch, for example, will first be built in CircleCI and then pushed directly from there to the
develop-built branch. The built code will then be deployed automatically.
For Node.js environments, there is a build step and certain other requirements. Code changes will only deploy (and replace any existing running code) if that code is successfully built. Review the requirements carefully and test them locally before merging to a production branch.
Overview of the build and deploy flow
Custom scripts and a CI service other than CircleCI can be used. The instructions below and scripts referenced are provided only as a convenience.
The steps listed below are a general example for development and deployment to a production environment using a build and deploy flow:
- Create a branch from
productionfor a new feature.
- Make the necessary modifications to the source files and commit them to the branch.
- Commit any changes to the dependencies (e.g.
.gitignorethe directories and files that npm modifies (e.g.
/node_modules/and anything else that gets built).
- Create a pull request. After the pull request has been reviewed and approved, merge it to
- Build: The build steps are run on the CI service.
- Deploy: VIP’s deploy script commits and pushes the build code to the
production-builtbranch. It is then immediately deployed to a production site.
Last updated: January 10, 2024