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.

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.

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 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.