Что такое The Twelve-Factor App?

Что такое The Twelve-Factor App (Двенадцать факторов приложения)?

The Twelve-Factor App — это методика, набор принципов для построения современных, масштабируемых и надежных веб-приложений, особенно в контексте облачных платформ (SaaS). Она была предложена в 2011 году разработчиками платформы Heroku и быстро стала de facto стандартом для разработки архитектуры микросервисов и cloud-native приложений. Основная цель — создание приложений, которые легко развертывать, масштабировать, поддерживать и переносить между различными облачными окружениями.

Эта методика особенно актуальна для PHP Backend, хотя многие принципы универсальны. Применение этих факторов помогает избежать типичных проблем "унаследованных" монолитных приложений: сложность развертывания, конфликты зависимостей, низкая масштабируемость, трудности в совместной работе разработчиков.

---

Двенадцать факторов (принципов)

1. I. Единственный код (Codebase)

    Одно приложение — один репозиторий (например, Git). Этот репозиторий используется для всех развертываний (разных environments: development, staging, production). Если есть несколько сервисов (микросервисов), каждый должен иметь свой собственный репозиторий.

1. II. Зависимости (Dependencies)

    Приложение должно явно объявлять и изолировать все свои зависимости. В PHP это реализуется через **Composer** с файлом `composer.json`. Никогда не следует предполагать наличие системных библиотек в окружении. Все зависимости должны быть явно указаны и управляться через инструменты управления зависимостями.

```php
// Пример composer.json
{
    "require": {
        "laravel/framework": "^10.0",
        "guzzlehttp/guzzle": "^7.5"
    }
}
```

3. III. Конфигурация (Config)

    Конфигурация, которая может меняться между развертываниями (ключи API, настройки базы данных, переменные окружения), должна храниться **вне кода**, обычно в **environment variables**. Это гарантирует безопасность (секреты не в репозитории) и гибкость.

```php
// В PHP доступ к переменным окружения
$databaseHost = getenv('DB_HOST');
// или через Symfony Dotenv, Laravel .env (но конечные значения из окружения)
```

4. IV. Сторонние службы (Backing services)

    Все сторонние службы (базы данных, кэши, брокеры сообщений, SMTP) рассматриваются как **присоединенные ресурсы** и адресуются через URL или другие конфигурационные данные (из переменных окружения). Приложение не должно различать локальную и стороннюю службу. Например, легко заменить локальный MySQL на облачный Amazon RDS.

1. V. Стадия построения, стадия выполнения (Build, release, run)

    Процесс поставки приложения четко разделяется на три стадии:
    * **Build** — превращение кода в исполняемый пакет (например, через Composer install, создание дистрибутива).
    * **Release** — объединение построенного пакета с конфигурацией (из переменных окружения). Результат — готовый, неизменяемый релиз.
    * **Run** — запуск этого релиза в целевой environment. Это разделение обеспечивает строгий контроль и возможность отката.

1. VI. Процессы (Processes)

    Приложение должно выполняться как один или несколько **независимых процессов** (обычно в виде демонов). Они не хранят состояние в памяти между запросами. В PHP это естественно, так как каждый запрос обрабатывается независимо (особенно при использовании PHP-FPM). Любое состояние должно храниться в backing services (базе данных, кэше).

1. VII. Привязывание портов (Port binding)

    Приложение должно быть **самостоятельным** и объявлять свои интерфейсы через привязывание к порту. Вместо использования внешнего веб-сервера (например, Apache) для запуска PHP, приложение должно включать свой веб-сервер и слушать на порту. В PHP это реализуется через **PHP-FPM** в сочетании с Nginx (не совсем чистая привязка порта), но более современные подходы используют, например, **FrankenPHP** или приложения на основе **ReactPHP**, которые могут сами слушать порт.

```bash
# Пример запуска FrankenPHP, который сам слушает порт 8000
frankenphp run --port=8000
```

8. VIII. Конкуренция (Concurrency)

    Приложение масштабируется через **горизонтальное масштабирование** — запуск большего количества процессов (workers), а не через вертикальное масштабирование (более мощный сервер). Для PHP это означает готовность запускать несколько идентичных процессов (через PHP-FPM workers) и использовать очереди (например, через Redis и Laravel Queues) для обработки задач.

1. IX. Утилизируемость (Disposability)

    Процессы приложения должны быть **быстро запускаемыми и легко завершаемыми**. Это позволяет быстро масштабировать, выполнять развертывания без downtime и быть устойчивым к сбоям. PHP процессы обычно запускаются быстро. Ключевое — минимизация времени запуска (оптимизация автозагрузки Composer) и graceful shutdown (корректная обработка сигналов завершения).

1. X. Parity between development and production (Сходство разработки и эксплуатации)

    Окружения разработки, staging и production должны быть **максимально похожими**. Это сокращает риски и "works on my machine" проблемы. Используйте одинаковые backing services (например, Docker для локальной базы данных), одинаковые версии PHP, одинаковые инструменты развертывания.

1. XI. Журналирование (Logs)

    Приложение должно рассматривать журналирование как поток событий и **не заниматься их управлением** (не писать в файлы, не ротировать). Логи должны направляться в stdout (стандартный вывод), а затем собираться внешними системами (например, ELK Stack, Loki, облачные сервисы). В PHP это означает использование стандартных потоков или интеграцию с мониторингом.

```php
// Вместо записи в файл, логи направляются через Monolog в stdout
$logger = new Monolog\Logger('name');
$logger->pushHandler(new Monolog\Handler\StreamHandler('php://stdout'));
```

12. XII. Административные процессы (Admin processes)

    Задачи административного характера (миграции базы данных, запуск скриптов, админские команды) должны выполняться как **одноразовые процессы** в идентичном окружении, как и основное приложение. В PHP это часто реализуется через CLI скрипты или команды фреймворков (например, Artisan в Laravel), которые используют тот же код и конфигурацию.

```bash
# Пример запуска миграций в Laravel
php artisan migrate --env=production
```

---

Значение для PHP Backend разработчика

Для PHP разработчика соблюдение этих принципов означает переход к более профессиональной, промышленной разработке. Это особенно важно при работе с микросервисами, Docker и облачными платформами (AWS, Google Cloud). Ключевые инструменты в PHP экосистеме, такие как Composer, PHP-FPM, Docker, и фреймворки типа Laravel или Symfony, уже предоставляют возможности для реализации многих факторов. Например, Laravel по умолчанию использует .env файлы для конфигурации (фактор III), Composer для зависимостей (фактор II), Artisan для админ процессов (фактор XII).

Игнорирование этих принципов может привести к созданию приложения, которое сложно масштабировать, развертывать, которое имеет секреты в коде и нестабильно в production. В современной разработке понимание и применение The Twelve-Factor App является одним из признаков высокого уровня expertise в области Backend и DevOps культуры.