Build and deploy

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.

Application environments that use continuous integration and deployment (CI/CD) on VIP should be configured with the -built branch as the deploying branch. For example, a develop environment should have CI/CD set up with a GitHub Actions workflow. The workflow builds new changes from the develop branch, then pushes those built changes to the develop-built branch. When the workflow commits new changes to the develop-built branch, they are automatically deployed to the environment.

Overview of the build and deploy flow

The steps listed below are a general example for development and deployment to a production environment that is using a build and deploy flow. In this example, the repository has an existing production and production-built branch and the production-built branch is already configured to deploy to the production environment.

1. Create a branch from the production branch for a new feature.
2. Make the necessary modifications to the source files and commit them to the branch.
3. Commit any changes to the dependencies (e.g. package.json, package.lock), but .gitignore the directories and files that npm modifies (e.g. /node_modules/ and anything else that gets built).
4. Create a pull request. After the pull request has been reviewed and approved, merge it to production.
5. Build: The build steps are run on the CI service.
6. Deploy: VIP’s deploy script commits and pushes the built code to the production-built branch. The code in the production-built branch is then immediately deployed to a production site.

Node.js requirements

Node.js applications have their own set of requirements for successful builds and deploys including a specific build step. Code changes will only deploy and replace any existing running code if that code is successfully built. Carefully review the requirements for a Node.js application to run successfully on VIP’s infrastructure. Test all code locally and on a non-production environment before merging to a production branch.

Add development-only files to .gitignore

Build and code management files should only be used in local development and should not be committed to an application’s wpcomvip GitHub repository. As a preventative measure, build and management files should be added to the repository’s .gitignore.

An incomplete list of build and code management files that should be added to .gitignore:

• .svnignore
• .svn
• config.rb
• Grunt, Gulp, or other build files
• PHPUnit or other testing files
• node_modules directories that contain devDependencies.
• vendor directories that contain build only files
• Files or directories that are only used for building locally
• Platform-specific binary files

As an added precaution, the node_modules directory is already added to .gitignore in the vip-go-node-skeleton for Node.js applications and in the vip-go-skeleton for WordPress applications. It is likely for a node_modules directory to contain platform-specific binary files that cannot be run. The presence of these files can cause performance issues for the application.

A warning message will be output in the comments of a pull request if a node_modules directory is found in the target branch for the pull request. Because of this, the warning message can occur even if the pull request is not adding the node_modules directory.