Процесс создания новой сборки и выпуска ее в производство является критическим этапом в SDLC, но он часто остается второстепенным и сильно варьируется от одной компании к другой.
Я надеюсь, что люди поделятся улучшениями, которые они внесли в этот процесс в своей организации, чтобы мы все могли предпринять шаги, чтобы «уменьшить боль».
Итак, вопрос в том, укажите одну болезненную / трудоемкую часть процесса выпуска и что вы сделали для ее улучшения?
Мой пример: у предыдущего работодателя все разработчики вносили изменения в одну общую базу данных разработки. Затем, когда подошло время выпуска, мы использовали Redgate SQL Compare, чтобы сгенерировать огромный скрипт из различий между базами данных Dev и QA.
Это работает достаточно хорошо, но проблемы с этим подходом: -
- Включены ВСЕ изменения в базе данных Dev, некоторые из которых все еще находятся в стадии разработки.
- Иногда разработчики вносили противоречивые изменения (которые не были замечены до тех пор, пока релиз не был запущен в производство)
- Создание и проверка сценария занимала много времени и выполнялась вручную (под проверкой я имею в виду попытку отсеять такие проблемы, как проблема 1 и 2).
- Когда возникали проблемы со сценарием (например, порядок, в котором все выполнялось, например, создание записи, которая опирается на запись внешнего ключа, которая есть в сценарии, но еще не запущена), потребовалось время, чтобы `` настроить '' ее, чтобы она работала плавно .
- Это не идеальный сценарий для непрерывной интеграции.
Итак, решение было: -
- Принудительная политика всех изменений в базе данных должна быть написана сценарием.
- Соглашение об именах было важно для обеспечения правильного порядка выполнения скриптов.
- Создать / использовать инструмент для запуска скриптов во время выпуска.
- У разработчиков была собственная копия базы данных, на которую они разрабатывали (так что больше не было «наступать друг другу на пятки»).
Следующий выпуск после того, как мы начали этот процесс, был намного быстрее с меньшим количеством проблем, действительно, единственные обнаруженные проблемы были из-за того, что люди «нарушали правила», например, не создавали скрипт.
Как только проблемы с выпуском в QA были исправлены, когда пришло время выпускать в продакшн, все прошло очень гладко.
Мы применили несколько других изменений (например, введение CI), но это было наиболее значительным, в целом мы сократили время выпуска с 3 часов до 10-15 минут.
