Все эти разговоры про "ускорение доставки качественного ПО" звучат так, будто кто-то продаёт тебе зубную пасту, а не рассказывает, как задеплоить Laravel. Давай по делу: CI/CD — это просто автоматизация рутины, чтобы не руками гонять тесты и не материться ночью на прод.

Если ты думаешь, что CI/CD — это нажать кнопку и жить спокойно, то обломись. Тут нужен не только кодерский мозг, но и немного админской паранойи. Без этого всё быстро превратится в цирк.

CI/CD — это не игрушка для фронтендеров, где можно пощёлкать конфиги и радоваться. Это больше похоже на грязную работу механика: руки в масле, под ногами лужа, а клиент требует, чтобы тачка поехала.

Laravel в связке с CI/CD — штука хорошая, но тут нужен не только "я программист, я пишу код". Тут нужен человек, который понимает, как PHP крутится на сервере, что такое зависимости, какие пакеты падают в самый неподходящий момент, и почему твой Docker внезапно начал хавать всю память.

Короче, хочешь CI/CD — готовься быть чуточку девопсом, чуточку админом, и много кем ещё.

GitHub Actions: сказка для ленивых

С GitHub Actions всё вроде бы красиво: кинул в репозиторий .github/workflows/ci.yml и как будто бы живёшь.

name: Laravel CI

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: '7.4'
        coverage: none

    - name: Validate composer.json and composer.lock
      run: composer validate

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

    - name: Run tests
      run: vendor/bin/phpunit

Красиво? Да. Работает? Иногда.

Реальность такая: рано или поздно у тебя тесты будут падать не потому, что код говно, а потому что какой-то пакет в composer обновился, а GitHub Actions решил: "ну, удачи". Или PHP расширение не поставилось, потому что у них там в Ubuntu что-то сломалось. И ты такой уже не программист, а сапожник, который чинит окружение.

GitLab CI/CD: суровее, но честнее

GitLab CI — это как GitHub Actions, только без розовых очков. Тут тебе сразу дают по рукам: "хочешь билдить — пиши чёткий .gitlab-ci.yml, иначе обломись".

image: php:7.4

stages:
 - test

cache:
  paths:
    - vendor/

before_script:
  - apt-get update -yqq
  - apt-get install -yqq git
  - docker-php-ext-install pdo_mysql
  - curl -sS https://getcomposer.org/installer | php
  - php composer.phar install

test:
  script:
    - ./vendor/bin/phpunit

И вот тут начинается "настоящая жизнь". Composer может умереть прямо на установке. pdo_mysql иногда собирается дольше, чем ты пишешь фичу. А твой кэш vendor/ может внезапно протухнуть.

В такие моменты ты уже не разработчик, а половина системного администратора, который ковыряет логи, матерится на CI-раннеры и думает, может ли оно вообще работать.

Почему без девопс-замашек не обойтись

CI/CD — это не "я код написал, а оно само". Это "я написал код, YAML, починил пакеты, пересобрал контейнер, доковырял окружение, и только потом оно как-то заработало".

И да, если ты думаешь, что это навсегда избавит тебя от ручных деплоев — забудь. Всегда найдётся момент, когда придётся залезть на сервер по SSH и ковыряться руками, потому что пайплайн сдох, а релиз надо катить сейчас.

Поэтому CI/CD для Laravel — это штука, где ты вынужден быть не только программистом. Тебе нужно знать Linux, Docker, PHP-расширения, Composer, и уметь дебажить то, что вообще не похоже на твою зону ответственности.

Итог

CI/CD — полезная штука, но сказки про "автоматическую доставку качественного ПО" оставь маркетологам. Настоящая жизнь такая: если хочешь, чтобы оно работало, придётся быть чуть-чуть девопсом, чуть-чуть админом, и всегда готовым чинить чужие косяки.