Разработка кода и здоровый шмептицизм

Note to self: когда есть задача выключить из проекта тот или иной контриб-модуль, никогда не надо в этой же задаче требовать убрать сам код модуля из проекта.

На примере Drupal: во всех деплой-скриптах, что мне доводилось видеть или писать, composer install (установка/обновление/удаление зависимостей) всегда идет первее drush updb (миграции БД) и drush cim (импорт загруженной из гита конфигурации). И это разумно в большинстве случаев: сначала при деплое мы тянем из интернета новые зависимости, затем запускаем миграции БД, требуемые этими зависимостями, затем применяем конфиг для этих зависимостей, включая yml-файлы с настройками нового модуля.

Однако при удалении модуля всё происходит наоборот: сначала нам нужно применить конфиг, в котором модуль «выключается» из системы. при этом будут удалены yml с его настройками, а также вызваны нужные обратные миграции БД. И только потом уже нам нужно вызвать composer install чтобы композер заметил отсутствие модуля в зависимостях и удалил его из кода.

Поэтому если мы единым мердж реквестом подадим отключение модуля (т.е. конфиг в котором модуль отключен) и удаление его из кодовой базы (удаление зависимости из composer.json например), то результатом деплоя будет ошибка. Поскольку скрипт сначала удалит кодовую базу, а потом уже попытается выполнить уже удаленный код, связанный с деинсталляцией. В результате деплой потребуется чинить вручную и тривиальная задача потребует времени в два раза больше нужного. Это как минимум, а если у нас скажем мультисайтинг с одной кодовой базы на 50 инстансов, вручную чинить уже вообще не захочется.

В общем, вместо требования удалить модуль сразу из кодовой базы лучше время от времени создавать maintenance-задачу по удалению из списка зависимостей неиспользуемых и уже ранее отключенных библиотек.

👌4

30 views12:56