GitHub
V. Сборка, релиз, выполнение
Строго разделяйте стадии сборки и выполнения
Кодовая база трансформируется в развёртывание (не учитывая развёртывание для разработки) за три этапа:
- Этап сборки – это трансформация, которая преобразует репозиторий кода в исполняемый пакет, называемый сборка. Используя версию кода по указанному процессом развёртывания коммиту, этап сборки загружает сторонние зависимости и компилирует двоичные файлы и ресурсы (assets).
- Этап релиза принимает сборку, полученную на этапе сборки, и объединяет её с текущей конфигурацией развёртывания. Полученный релиз содержит сборку и конфигурацию и готов к немедленному запуску в среде выполнения.
- Этап выполнения (также известный как “runtime”) запускает приложение в среде выполнения путём запуска некоторого набора процессов приложения из определённого релиза.
Приложение двенадцати факторов использует строгое разделение между этапами сборки, релиза и выполнения. Например, невозможно внести изменения в код во время выполнения, так как нет способа распространить эти изменения обратно на этап сборки.
Инструменты развёртывания, как правило, представляют собой инструменты управления релизами, и что немаловажно, дают возможность отката к предыдущему релизу. Например инструмент развёртывания Capistrano сохраняет релизы в подкаталогах каталога с именем releases, где текущий релиз является символической ссылкой на каталог текущего релиза. Команда Capistrano rollback даёт возможность быстро откатится к предыдущему релизу.
Каждый релиз должен иметь уникальный идентификатор, такой как отметка времени релиза (например 2015-04-06-15:42:17) или увеличивающееся число (например v100). Релизы могут только добавляться и каждый релиз невозможно изменить после его создания. Любые изменения обязаны создавать новый релиз.
Сборка инициируется разработчиком приложения всякий раз, когда разворачивается новый код. Запуск этапа выполнения, напротив, может происходить автоматически в таких случаях, как перезагрузка сервера, или перезапуск упавшего процесса менеджером процессов. Таким образом, этап выполнения должен быть как можно более технически простым, так как проблемы, которые могут помешать приложению запуститься могут возникнуть в середине ночи, когда нет доступных разработчиков. Этап сборки может быть более сложным, так как возможные ошибки всегда видимы разработчику, который запустил развёртывание.