CI/CD for PHP Projects: GitHub Actions from A to Z

Introduction to CI/CD for PHP Projects with GitHub Actions

Modern PHP application development is impossible without automation. Manual testing and deployment are not only time-consuming but also error-prone. CI/CD (Continuous Integration / Continuous Deployment) solves these problems by automating code checks and delivery to the server. One of the most popular tools for this is GitHub Actions.

GitHub Actions is a built-in platform for automating workflows, which allows you to run tests, linters, builds, and deployments directly from your GitHub repository. In this article, we will cover how to set up a complete CI/CD pipeline for a PHP project: from simple test execution to automatic deployment to a production server.

We will use an example based on Laravel, but all principles apply to any PHP framework (Symfony, Yii, WordPress, etc.). You will learn how to write YAML configurations, use testing matrices, cache dependencies, and deploy code securely.

Main Part

1. GitHub Actions Basics: Workflow Structure

A workflow is an automated process triggered by a specific event (push, pull request, tag creation). Each workflow is described in a YAML file stored in the .github/workflows/ directory of your repository.

Basic structure of the .github/workflows/ci.yml file:

name: CI Pipeline

on:  push:    branches: [ main, develop ]  pull_request:    branches: [ main ]

jobs:  test:    runs-on: ubuntu-latest

    steps:      - name: Checkout repository        uses: actions/checkout@v4

      - name: Setup PHP        uses: shivammathur/setup-php@v2        with:          php-version: '8.2'          extensions: mbstring, xml, bcmath, pdo_mysql          coverage: xdebug

      - name: Install dependencies        run: composer install --no-progress --prefer-dist

      - name: Run PHPUnit tests        run: vendor/bin/phpunit --coverage-text

Let's break down the key elements:

• on — triggers: push to main/develop, pull request to main.
• jobs — a set of tasks (jobs) executed in parallel or sequentially.
• runs-on — the operating system for execution (usually ubuntu-latest).
• steps — a sequence of steps within a job.
• uses — ready-made actions from the marketplace (e.g., shivammathur/setup-php).
• run — execution of a shell command.

2. Advanced Configuration: Testing Matrix and Caching

For larger projects, it is useful to test multiple PHP versions and dependencies simultaneously. This is done using a matrix strategy. It is also important to cache the Composer vendor folder to speed up workflow execution.

Example with a matrix and cache:

name: Advanced CI

on: [push, pull_request]

jobs:  test:    runs-on: ubuntu-latest    strategy:      matrix:        php: [ '8.1', '8.2', '8.3' ]        dependency-stability: [ prefer-stable, prefer-lowest ]

    steps:      - uses: actions/checkout@v4

      - name: Setup PHP        uses: shivammathur/setup-php@v2        with:          php-version: ${{ matrix.php }}          extensions: mbstring, pdo, gd          coverage: none

      - name: Cache Composer packages        uses: actions/cache@v3        with:          path: vendor          key: ${{ runner.os }}-php-${{ matrix.php }}-composer-${{ hashFiles('**/composer.lock') }}          restore-keys: |            ${{ runner.os }}-php-${{ matrix.php }}-composer-

      - name: Install dependencies        run: composer install --${{ matrix.dependency-stability }} --no-interaction

      - name: Run test