12 factor app: кодовая база
12 factor app — чеклист из 12 пунктов для адаптации сервиса к облаку.
Список появился в 2017 году, и был модным года до 20. Упоминание 12 факторов на собеседовании производило вау-эффект и приводило интервьюеров в восторг:)
Большинство идей до сих пор актуальны. Но
🤔 Оригинальный текст очень формальный, иногда это просто набор терминов и процессов. Не написано, в чём смысл, и какая проблема решается. Когда цель непонятна, работа превращается в карго культ или бесполезные движения
🤔 Не всегда понятны конкретные шаги. Иногда это "делайте хорошо, плохо не делайте"
🤔 Некоторые рекомендации в оригинальном тексте слишком жёсткие или устарели
Так что потихоньку пройдусь по всем пунктам, объясню суть и дам более актуальные рекомендации, чем в оригинале.
Первый пункт посвящён работе с кодовой базой и звучит так: one codebase tracked in revision control, many deploys
Приложение полностью отслеживается системой контроля версий.
Экземпляр запущенного приложения называется deploy. Неважно, где он запущен — в проде, локально у разработчика или в тестовой среде. Хотя в жизни чаще используются другие термины (билд, артефакт или просто сервис), дальше буду использовать оригинальный термин.
🔸 У каждого сервиса своя кодовая база в одном репозитории.
🔸 У разных приложений разные кодовые базы. Общий код выделяется в библиотеку/модуль и импортируется через менеджер зависимостей.
🔸 У каждого приложения одна кодовая база, но на разных средах могут использоваться разные версии. Например, локально у разработчика запускается ветка с фичей, тестировщик работает с мастером, на проде разворачивается релизная ветка.
В чем смысл ограничений: если продакшн использует одну кодовую базу, а разработка и тестирование — немного другую, однажды появится ошибка, которая воспроизведётся только на продакшене.
На практике вполне нормально, что для разных сред код работает по-разному. Обычно изменения касаются внешних компонентов.
Яркий пример — платёжная система. Работать с настоящими деньгами — непозволительная роскошь, поэтому для разработки и тестирования используются либо заглушки, либо специальные песочницы.
Как проверить приложение:
✅ В коде нет условий вроде
✅ Общие модули импортируются через менеджер зависимостей — Maven или Gradle
✅ Финальный этап тестирования происходит на версии, которая потом отправится в продакшн
12 factor app — чеклист из 12 пунктов для адаптации сервиса к облаку.
Список появился в 2017 году, и был модным года до 20. Упоминание 12 факторов на собеседовании производило вау-эффект и приводило интервьюеров в восторг:)
Большинство идей до сих пор актуальны. Но
🤔 Оригинальный текст очень формальный, иногда это просто набор терминов и процессов. Не написано, в чём смысл, и какая проблема решается. Когда цель непонятна, работа превращается в карго культ или бесполезные движения
🤔 Не всегда понятны конкретные шаги. Иногда это "делайте хорошо, плохо не делайте"
🤔 Некоторые рекомендации в оригинальном тексте слишком жёсткие или устарели
Так что потихоньку пройдусь по всем пунктам, объясню суть и дам более актуальные рекомендации, чем в оригинале.
Первый пункт посвящён работе с кодовой базой и звучит так: one codebase tracked in revision control, many deploys
Приложение полностью отслеживается системой контроля версий.
Экземпляр запущенного приложения называется deploy. Неважно, где он запущен — в проде, локально у разработчика или в тестовой среде. Хотя в жизни чаще используются другие термины (билд, артефакт или просто сервис), дальше буду использовать оригинальный термин.
🔸 У каждого сервиса своя кодовая база в одном репозитории.
🔸 У разных приложений разные кодовые базы. Общий код выделяется в библиотеку/модуль и импортируется через менеджер зависимостей.
🔸 У каждого приложения одна кодовая база, но на разных средах могут использоваться разные версии. Например, локально у разработчика запускается ветка с фичей, тестировщик работает с мастером, на проде разворачивается релизная ветка.
В чем смысл ограничений: если продакшн использует одну кодовую базу, а разработка и тестирование — немного другую, однажды появится ошибка, которая воспроизведётся только на продакшене.
На практике вполне нормально, что для разных сред код работает по-разному. Обычно изменения касаются внешних компонентов.
Яркий пример — платёжная система. Работать с настоящими деньгами — непозволительная роскошь, поэтому для разработки и тестирования используются либо заглушки, либо специальные песочницы.
Как проверить приложение:
✅ В коде нет условий вроде
if (env == dev). Переключение между заглушками и настоящими системами происходит через конфиг✅ Общие модули импортируются через менеджер зависимостей — Maven или Gradle
✅ Финальный этап тестирования происходит на версии, которая потом отправится в продакшн