У меня есть репозиторий кода Kiln / Mercurial для веб-приложения, которое использует Cruise Control.NET для непрерывной интеграции. Обычно мы фиксируем наш код локально, и когда мы готовы к тестированию, мы отправляем его на центральный сервер печи. Круиз-контроль регулярно проверяет репозиторий на этом сервере на наличие новой версии и, когда находит ее, создает ее и копирует полученные файлы на соответствующий веб-сервер. Если он пройдет проверку, мы вручную принудительно выполним сборку на нашем основном производственном сервере, и все будет хорошо.
Однако недавно у нас произошла небольшая икота. Мы обнаружили ошибку в версии, выпущенной в производство в прошлом месяце, и ее необходимо исправить. С тех пор было совершено около 50 коммитов, и код, представленный в этих 50 коммитах, еще далек от готовности к производству. Мы знаем, что можем локально откатиться (обновить) до версии, которая была запущена в производство, и исправить код, но у нас нет возможности отправить это в Kiln и передать в круиз-контроль - Mercurial на сервере Kiln жалуется на несколько головы. Как лучше всего с этим справиться?
Мы немного погуглили и нашли ссылки на ветвление и теги. В итоге мы сделали новую ветку в репозитории на сервере Kiln. В этой ветке был наш основной репозиторий за вычетом этих 50 коммитов. Затем мы исправили нашу ошибку и отредактировали конфигурацию круиз-контроля, чтобы искать ее там, а не в основном репозитории. После нескольких сборок мы исправили нашу ошибку на рабочем сервере. Это похоже на существенный объем работы, чтобы откатиться, исправить и отправить это на веб-сервер.
Поскольку мы - небольшой магазин, у нас обычно есть собственные проекты, над которыми нужно работать. Не было преднамеренного ветвления (до сих пор) и даже минимального слияния, поэтому, хотя мы не новички в управлении версиями, есть несколько общих аспектов этой концепции, с которыми нам еще не приходилось иметь дело.