Парни из Heroku предложили набор общих концептуальных решений проблем, которые наиболее часто возникают при разработки и поддержке веб-приложений.
Важно не забывать, что Приложение двенадцати факторов(The Twelve-Factor App) — это методология для создания SaaS-приложений, а не свод законов по разработки любого ПО. Другими словами это оптимальные решения в усредненном проекте. В конкретных ситуациях возможные более эффективные решения, тем более при разработке другого типа приложений.
1. Codebase (Кодовая база)
Одна кодовая база, отслеживаемая в системе контроля версий, – множество развёртываний
Весь код приложения должен быть в системе контроля версий. И разворачиваться для разработки, тестирования и на рабочих серверах из одного репозитория. Если у вас несколько приложений используют общий код, то общий код надо выделить в отдельную библиотеку, и объявить ее как зависимость.
2. Dependencies (Зависимости)
Явно объявляйте и изолируйте зависимости
Приложение двенадцати факторов никогда не зависит от неявно существующих, доступных всей системе пакетов. Приложение объявляет все свои зависимости полностью и точно с помощью манифеста декларации зависимостей. Кроме того, оно использует инструмент изоляции зависимостей во время выполнения для обеспечения того, что неявные зависимости не “просочились” из окружающей системы. Полная и явная спецификация зависимостей применяется равным образом как при разработке, так и при работе приложения.
3. Config (Конфигурация)
Сохраняйте конфигурацию в среде выполнения
Конфигурация приложения – это всё, что может меняться между развёртываниями (среда разработки, промежуточное и рабочее развёртывание). Кодовая база приложения может быть в любой момент открыта в свободный доступ без компрометации каких-либо приватных данных. Приложение двенадцати факторов хранит конфигурацию в переменных окружения.
4. Backing services (Сторонние службы)
Считайте сторонние службы (backing services) подключаемыми ресурсами
Сторонняя служба– это любая служба, которая доступна приложению по сети и необходима как часть его нормальной работы. Код приложения двенадцати факторов не делает различий между локальными и сторонними сервисами. Для приложения каждый из них является подключаемым ресурсом, доступным по URL-адресу или по другой паре расположение/учётные данные, хранящимися в конфигурации.
5. Build, release, run (Сборка, релиз, выполнение)
Строго разделяйте стадии сборки и выполнения
Кодовая база трансформируется в развёртывание за три этапа:
Этап сборки – это трансформация, которая преобразует репозиторий кода в исполняемый пакет, называемый сборка. Этап релиза принимает сборку, полученную на этапе сборки, и объединяет её с текущей конфигурацией развёртывания. Этап выполнения (также известный как “runtime”) запускает приложение в среде выполнения путём запуска некоторого набора процессов приложения из определённого релиза.
6. Processes (Процессы)
Запускайте приложение как один или несколько процессов, не сохраняющих внутреннее состояние (stateless)
Процессы приложения двенадцати факторов не сохраняют внутреннее состояние (stateless) и не имеют разделяемых данных (share-nothing). Любые данные, которые требуется сохранить, должны быть сохранены в хранящей состояние сторонней службе.
7. Port binding (Привязка портов)
Экспортируйте сервисы через привязку портов
Приложение двенадцати факторов является полностью самодостаточным и не полагается на инъекцию веб-сервера во время выполнения для того, чтобы создать веб-сервис. Веб-приложение экспортирует HTTP-сервис путём привязки к порту и прослушивает запросы, поступающих на этот порт.
8. Concurrency
Масштабируйте приложение с помощью процессов
Обработкой разных задач должны заниматься разные процессы. Процессы приложения двенадцати факторов никогда не должны демонизироваться и записывать PID файлы. Вместо этого они должны полагаться на менеджер процессов операционной системы.
9. Disposability (Утилизируемость)
Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы
10. Dev/prod parity (Паритет разработки/работы приложения)
Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими
11. Logs (Журналирование)
Рассматривайте журнал как поток событий
Журнал – это поток агрегированных, упорядоченных по времени событий, собранных из потоков вывода всех запущенных процессов и вспомогательных сервисов. Каждый выполняющийся процесс записывает свой поток событий без буферизации в стандартный вывод stdout.
12. Admin processes (Задачи администрирования)
Выполняйте задачи администрирования/управления с помощью разовых процессов