Отслеживание развертываний во многих командах в среде, как это делают профессионалы?

Question

Сценарий: у нас был перерыв в одной из наших сред. Оказывается, кто-то развернул новую версию представления, нарушившего чужой код. Потребовалось некоторое время, чтобы выследить это. Получил меня к удивлению все же.

Существует ли передовая практика управления развертыванием во многих группах? Что вы думаете о хорошей практике управления этим?

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

Answer 1

Есть ли передовая практика для управления развертыванием во многих командах? Что вы думаете о хорошей практике управления этим?

Самый простой способ - выполнить развертывание как часть процесса непрерывной интеграции. Как вручную, так и автоматически сборки могут быть развернуты через равные промежутки времени или по достижении некоторого порога.

Поскольку большинство серверов CI поддерживают некоторый уровень аудита, будет несложно увидеть, какие изменения были внесены в конкретное развертывание, что может привести к поломке. Это решает сразу несколько проблем:

• Принудительное исполнение. Только люди, которые могут развернуть сборку, смогут развернуть в производство таким способом. Доступ контролируется CI.

• Усыновление: Тривиально. Никто не должен делать ничего, кроме нажатия кнопки, чтобы начать развертывание.

• Обратная совместимость: сложнее. Вам нужно было бы более четко определить, какие требования вы должны поддерживать, но есть хорошие шансы, что их тоже выбьют.

Answer 2

Я столкнулся с ситуацией, аналогичной описанной вами. То, как нам удалось это исправить, очень похоже на то, что вы сказали. Мы уделяем большое внимание документации и одобрению. Каждое (нетривиальное) изменение в коде должно быть задокументировано, протестировано и одобрено другим лицом, прежде чем это изменение сможет перейти в разработку. У нас также есть возможность использовать TFS для планирования сборок и контроля версий.

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

Надеюсь, это поможет.