Title: Build and deploy
Author: WordPress VIP Documentation
Published: December 13, 2023
Last modified: June 24, 2025

---

 1. [Code deployment](https://docs.wpvip.com/code-deployment/)
 2. [Default Deployment](https://docs.wpvip.com/code-deployment/default-deployment/)
 3. Build and deploy

#  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](https://docs.wpvip.com/github-repository/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)](https://docs.wpvip.com/github-repository/build-and-deploy/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](https://docs.wpvip.com/code-deployment/default-deployment/#1-enable-default-deployment).
For example, a `develop` environment should have CI/CD set up with a [GitHub Actions](https://docs.wpvip.com/code-deployment/default-deployment/build-and-deploy/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

**Note**

[VIP recommends and provides GitHub Actions](https://docs.wpvip.com/code-deployment/default-deployment/build-and-deploy/github-actions/)
to create a build and deploy flow, but custom scripts and other CI services can 
also be used. The instructions and scripts referenced below 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](https://github.com/Automattic/vip-go-build/) 
    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](https://docs.wpvip.com/node-js/application-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](https://docs.wpvip.com/code-deployment/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](https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file)`.
 * `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](https://github.com/Automattic/vip-go-node-skeleton/tree/27c12a917d7b2ec40a82fce742d0f6f9be4935db)
for Node.js applications and in the [vip-go-skeleton](https://github.com/Automattic/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.

Last updated: June 24, 2025