Zero-downtime деплой на WordPress с Trellis: атомарни релийзи, rollback за секунди и чист workflow

В модерния app свят zero downtime deployments е базова хигиена: новата версия се подготвя отделно и се „превключва“ моментално. В WordPress екосистемата обаче все още често се виждат деплойи, при които файловете се презаписват директно върху работещ сайт — и точно тогава започват 500-ците, липсващи класове, полусвалени assets и счупени админ страници.

Trellis (Ansible-базиран tooling от Roots) има zero-downtime деплой стратегия out of the box чрез атомарни и immutable (непроменяеми) релийзи. Важно: не е нужно да ползваш Trellis за целия си локален development. Много екипи го използват само за деплой на Bedrock-базирани сайтове към различни хостинг среди (включително managed платформи), а локално работят с каквото им е удобно (Valet, Lando, DDEV и т.н.).

Какво реално означава „zero downtime“ при деплой

В контекста на WordPress деплой, zero downtime означава, че сайтът остава напълно достъпен и функционален през целия процес. Няма период, в който потребителите да попадат на микс от „стари“ и „нови“ файлове, защото никой не презаписва на място текущата версия.

Ключът е атомарното превключване: новият релийз се подготвя в изолирана директория, и едва когато е готов (код + зависимости + symlinks към споделени данни), web root се пренасочва към него мигновено.

Къде се чупят традиционните WordPress деплои

Най-разпространените подходи за WordPress деплой споделят един и същ структурен проблем: актуализират файловете „на живо“.

• FTP upload: бавен процес, при който сайтът може да сервира частично обновени файлове (стар PHP код + нови templates, или обратното).
• Синхронизация тип rsync: по-бързо е, но логиката е същата — overwrite върху активната версия.
• Plugin/host-based deployment: удобство срещу контрол; често пак се работи in-place и без истински rollback механизъм.

Общите последствия са познати: кратък прозорец с грешки по време на качване, невъзможност за моментално връщане назад, и потребители (или редактори) които уцелват сайта точно в лошия момент.

Атомарният подход на Trellis (и защо е различен)

Trellis използва атомарен deployment модел, типичен за съвременни приложения: всяко разгръщане създава нов, отделен релийз, който след това става активен чрез превключване на един symlink. След като релийзът е „пуснат“, файловете му не се модифицират in-place — това е идеята на immutable releases.

Структура на директориите на сървъра

При деплой Trellis изгражда предсказуема структура, в която активната версия винаги е зад symlink current:

/srv/www/example.com/
├── current/             # Symlink към активния релийз
├── releases/            # Всички деплойнати релийзи
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Най-новият
├── shared/              # Споделени файлове между релийзи
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink към активния релийз
├── releases/            # Всички деплойнати релийзи
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Най-новият
├── shared/              # Споделени файлове между релийзи
│   └── uploads/
└── logs/

Уеб сървърът сочи към current. А current сочи към конкретна директория в releases/. Така „смяната на версия“ става като Trellis обнови symlink-а — операция, която на практика е мигновена.

Какво се случва при trellis deploy production

Под капака Trellis минава през поредица от стъпки, които подготвят новия релийз извън live директорията:

1. Initialize: проверява/създава структурата и подготвя нова release директория (обикновено timestamp като 20250930141622).
2. Update: клонира/обновява кода от Git в отделна source директория, без да закача live сайта.
3. Prepare: копира/подготвя файловете в новия релийз.
4. Build: пуска composer install, за да дръпне PHP зависимостите.
5. Share: връзва споделени директории (например uploads/) от shared/ към новия релийз чрез symlink.
6. Finalize: обновява current да сочи към новия релийз.

Ефектът е прост за обяснение: в един момент current сочи към стар релийз, а в следващия — към нов. Няма междинна фаза с частично обновени файлове.

Базата данни: важният детайл, който не е „магически“ решен

Zero downtime на файлово ниво не означава автоматично zero downtime на ниво база данни. По документация на Trellis, миграции на схемата не са част от стандартния deploy процес. Тоест Trellis гарантира атомарност за кода, но DB промени трябва да ги планираш отделно.

Ако ползваш Acorn, можеш да работиш с Laravel migrations (познатия механизъм за versioning на DB промени) и да ги изпълняваш като част от деплой процеса. Това е практичен начин да сложиш дисциплина при промени в schema-та, но пак остава архитектурният въпрос: миграциите трябва да са съвместими с моментното превключване между версии (backward compatible, когато е нужно).

Rollback за секунди (истинският бонус на атомарните релийзи)

Когато всеки релийз е пълна, самостоятелна директория и не се пипа след активиране, rollback-ът е просто смяна на symlink към предишна версия. Trellis го дава като команда:

trellis rollback production

trellis rollback production

По подразбиране Trellis пази ограничен брой последни релийзи на сървъра (типично 5), което е достатъчно за бързо връщане при проблемен деплой, без да държиш безкрайни копия.

Deploy hooks: къде влиза custom логиката

В реални проекти деплой процесът рядко е само „дърпам код и пускам“. Trellis има hooks (куки) — точки, в които можеш да закачиш свои задачи преди/след ключови стъпки.

• deploy_build_before / deploy_build_after: за custom build стъпки около инсталацията/компилацията.
• deploy_finalize_before / deploy_finalize_after: за действия непосредствено преди/след превключването на current.
• Hooks за всяка голяма фаза: initialize, update, prepare, build, share, finalize.

Това отваря врата за практики като: backup на база преди деплой, чистене на кеш след деплой, нотификации към екип, или smoke тестове върху новия релийз (преди да стане активен, ако процесът ти го позволява).

Как да започнеш (без да сменяш целия си локален stack)

Минималният път до zero-downtime деплой с Trellis е сравнително директен:

1. Структурирай проекта с Bedrock (по-предсказуема WordPress структура и зависимости през Composer).
2. Инсталирай Trellis и конфигурирай deployment настройките.
3. В wordpress_sites.yml добави данните за Git репозиторито и средата (например production).
4. Пусни деплой с trellis deploy production.

Първото разгръщане обикновено е по-бавно, защото Trellis прави началната структура и сваля зависимостите. След това деплоите стават по-рутинни — и по-важното: без прозорец, в който сайтът да е в „полуобновено“ състояние.

Обобщение

Trellis решава класическия WordPress проблем с in-place деплой чрез атомарни, immutable релийзи: новата версия се подготвя изолирано и се активира с мигновено превключване на current symlink. Получаваш и моментален rollback, плюс hooks за интеграция на реални DevOps практики. Ако вече работиш с Bedrock и държиш на предсказуеми деплои без неприятни изненади за потребителите, това е една от най-прагматичните стъпки към „модерен“ WordPress deployment.