Title: Continuous integration and deployment (CI/CD) Author: WordPress VIP Documentation Published: September 15, 2020 Last modified: May 28, 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](https://docs.wpvip.com/code-deployment/default-deployment/build-and-deploy/) 4. Continuous integration and deployment (CI/CD) # Continuous integration and deployment (CI/CD) Continuous integration and continuous deployment [(CI/CD)](https://en.wikipedia.org/wiki/CI/CD) is supported in the [development workflow](https://docs.wpvip.com/development-workflow/) on the WordPress VIP Platform. Build processes can be used to optimize static resources, bundle CSS and JS, [use composer](https://docs.wpvip.com/use-composer-on-vip/) to fetch and install dependencies, and other related tasks. [GitHub Actions](https://docs.wpvip.com/code-deployment/github-repository/#0-github-actions) can be configured to run these build processes, then to deploy a built copy to a VIP environment. It is the customer’s responsibility to develop a method to build (e.g. run `npm install`), transpile, optimize, concatenate, and minify an application’s code. It should be possible for the method used to be automatically run by a script on a CI service, without intervention from a human. Ensure that any versioning updates (needed for cache busting, etc.) are part of the build process or part of the commit that triggers the build. Review [the documentation on concatenating assets](https://docs.wpvip.com/vip-go-mu-plugins/file-concatenation-and-minification/) to fully understand the complexities of combining built assets, page caching, and concatenated JS and CSS. Adjust asset build and deploy scripts to avoid any deploy- related issues that might affect new and immediately prior versions of asset files. When running the build process for production (i.e. `production-built`), ensure that the build process does not include development dependencies. The CI script should test the build, and flag any issues to the customer and their team. ## Push code to branches The deployable built branch should end in `-built`. For example, if a working branch is `production` (for a production environment) then a built branch should be `production- built`. For a develop environment, the working branch should be `develop` and the built and deployed branch should be `develop-built`. * **Never push code directly to the build branches** (e.g. `production-built`). Code should only be pushed to a working branch (e.g. `production`), which should then build the code and push a commit to the build branch. * For customers with the ability to [request a VIP code review](https://docs.wpvip.com/code-review/requesting-code-review/), the source code committed to the non-built branch will be reviewed. * Third-party dependencies brought in by the build process **will not be reviewed**( e.g. Javascript dependencies added via npm or yarn, or PHP SDKs/plugins/libraries added via Composer). ## Deploying built files from `.gitignore` By default, files and directories referenced in the `.gitignore` file in a repository will **not** be pushed to `production-built`. This includes files that are generated by the build process. To allow the built files to be pushed to a `-built` branch, create and use a `.deployignore` file. This file acts as a replacement for all `.gitignore` files in a repo. When preparing the deployment, [VIP’s deploy script](https://github.com/Automattic/vip-go-build/) removes all `.gitignore` files and uses `.deployignore` as the canonical, global`. gitignore` instead. To use a `.deployignore` file: 1. Make a copy of the root `.gitignore` file and name it `.deployignore`. If a `.gitignore` file does not yet exist in a repository, a new one can be created based on [the vip-go-skeleton `.gitignore` file](https://github.com/Automattic/vip-go-skeleton/blob/master/.gitignore). 2. Review any other `.gitignore` files in the repo and make sure that any relevant rules are copied over to the `.deployignore` file. Paths may need to be updated in order for these rules to start from the root of the repo. 3. Remove any rules that reference built or auto-generated files that **do need** to be deployed. 4. (Optional) Add any rules that reference source files that **do not need** to be deployed. ### Example `.gitignore` file An example of a basic `.gitignore` file: .gitignore ```lang-php # node_modules should almost never be committed. node_modules # /plugins/my-ui/src is omitted here since we do want that committed for development purposes. # This is where our built files are generated. We do not need to commit it. /plugins/my-ui/dist ``` The `.deployignore` file that is generated from the `.gitignore` file in the example above: .deployignore ```lang-php # node_modules should almost never be committed. node_modules # Our source files do not need to be deployed. /plugins/my-ui/src # /plugins/my-ui/dist is omitted here because we do want it deployed. ``` ### Example `.deployignore` file The contents of this example `.deployignore` file demonstrate common files and directories that could be fully removed from a `production-built` branch. .deployignore ```lang-plain # Development and other files that are not needed in production-built. .editorconfig .gitignore composer.json composer.lock .phpcs.xml phpcs.xml .phpcs.xml.dist readme.txt README.md !/README.md LICENSE license.txt webpack.config.js .cursor/ .devcontainer/ .github/ .wpvip/ node_modules/ docs/ /config/ # Composer - should not be pushed to *-built branches unless there is a runtime dependency in it. /client-mu-plugins/vendor/ ``` **Note** Do not include `.gitkeep` in the `.deployignore` file. While an application may not require directories such as `languages/` and `private/`, the presence of those directories are checked for, and the removal of the `.gitkeep` will result in those directories not being pushed to the `*-built` branches. ### Applications that use a non-VIP build system The `.deployignore` file will have no effect if an application is using a build system other than [GitHub Actions provided by VIP](https://docs.wpvip.com/code-deployment/default-deployment/build-and-deploy/github-actions/). All of the files and directories referenced in `.deployignore` will still be deployed. To control which files are not deployed, use the “build and deploy” functionality described on this page, or include some logic to control what gets built and what gets ignored by git (or removed) before pushing to the `production-built` or `production` branch, within the CI scripting of the other build system used by the application. Last updated: May 28, 2025