Лучшие практики по именованию и разграничению сред в соответствии с их предназначением, взаимному соответствию сред и ветвей кода, и процессу выпуска в условиях коробок и самописных монолитов старой школы.

Именование сред

Разработки [dev] — та среда (база данных, сайт, ВМ и т.д.), где развёртываем свежий код и смотрим, что получается.

Демо [demo] — тут промежуточный результат показывается заказчику. Пока развёрнутый здесь полуготовый функционал ждёт внимания заказчика, на [dev] можно всё сломать, работая дальше.

Тестовая [test] — тут тестируется функциональность. Среда наполнена тестовыми данными, которые могут отражать редко возникающие (в рабочей среде) случаи или быть удобными для тестирования. Пока тут идёт тестирование того, что готовится в продакшен, на [dev] уже появляется код следующего релиза.

Промежуточная [stage], она же предпродакшен — тут тестируется развёртывание. Сюда развёртывается последний бэкап системы из продакшена, чтобы проверить обновление на версию.

Продакшен [prod] — тут работают пользователи.

Связь конфигурации с кодом

Бывает, что код идёт в развёртывание вместе с конфигурацией (набором переносимых настроек) и, при этом, сам код ведётся в репозитории, а конфигурация в среде. При этом, конфигурация переносится через экспорт-импорт.

Изначально, код, попадающий в ветвь /dev, выкатывается в среду [dev], где настраивается конфигурация к нему. Затем, код и конфигурация (иногда по частям) переносятся в другие среды.

Путь кода

/dev → [dev]

/dev → [demo]

/dev → /main

/main → [test]

/main → [stage]

/main → [prod]

То, что исправляется в /main при тестировании, естественно → /dev.

Путь конфигурации

[dev] → [demo]

[dev] → экспорт в репозиторий конфигурации отдельно от кода.

репозиторий конфы → [test]

репозиторий конфы → [stage]

репозиторий конфы → [prod]

Помехи гладкому релизу

Рассмотрим, что в архитектуре ломает выпуск.

Двусторонняя зависимость

Бывает, что часть конфигурации зависит от собранного кода (от dll, jar и т. п.), но часть кода зависит от структур, создаваемых конфигуратором, либо от сборок, которые собираются конфигуратором.

Чтобы в кольцо не попасть, если что-то делается кодом, это нужно делать именно кодом. Например, в ELMA-BPM v.3.x можно создать объекты через конфигуратор, а можно через плагин к Visual Studio – выбирайте второе.

Большая и важная база данных

В системах с логикой в базе, бывает, разработчики катят её в единственный общий экземпляр БД. Обычно говорят, что эта база dev самая актуальная и наполненная.

Сегодня это архитектурное фиаско, которое сводится к описанному далее.

Одна-единственная среда

Из-за использования всего одной среды теряет смысл ветвление кода. Т. е. от /dev бессмысленно отделять фичи т. к. они столкнутся вместе в котле разработки раньше чем они там нужны.

Что это означает? Не получается вести длинные работы и короткие праллельно, не выходит соблюдать регулярность релизов.