Мы используем Mercurial уже пару месяцев, и это уже значительно улучшило наш процесс развертывания. Это хорошая часть.
Система, которая у нас есть, работает, но она по-прежнему подвержена ошибкам, если вы не будете осторожны или торопитесь. Это заставляет меня задуматься, есть ли способы, как мы могли бы это улучшить или ... может быть, мы полностью не в курсе:)
Наше окружение состоит из:
- Рабочая станция локального развития (каждый разработчик)
- Сервер разработки (хостинг БД и центрального хранилища)
- Сервер приема (где выполняется QA)
- промежуточный сервер (где мы размещаем ветвь релиза, мы затем выполняем робокопию к работающим системам)
Немного предыстории о причине, по которой мы перешли:
Мы находимся в рабочей среде, которая часто заставляет нас переключаться с задачи на задачу, оставляя много незавершенных задач. Многие из нас станут устаревшими и загромождут основную ветку, когда мы вернемся к CVS. Развертывание было кошмаром, так как вам приходилось обходить строки, которые нужно было запустить, и те, которые не использовали Beyond Compare.
Mercurial с именованными ветвями и простым слиянием решает эту проблему для нас. Поэтому, не зная, чего ожидать, мы настроили его.
Сначала мы очистили, очистили наш производственный источник, удалили мертвые файлы и т. Д.
Мы сделали это при подготовке по FTP и сделали наш новый репозиторий «по умолчанию», это должен был быть наш стабильный филиал, готовый к развертыванию в любое время.
После этого мы сделали hg clone для сервера разработки, и у каждого разработчика hg clone из ветви разработки по умолчанию.
При принятии, где мы проводим QA, мы сделали hg clone ветки сервера разработки по умолчанию.
На данный момент у нас есть стабильная копия кода везде, все хотят начать!
локальная машина толкает в dev, прием вытягивает из dev, и подготовка полностью изолирована и может тянуть откуда угодно, если путь обеспечен.
Теперь идея заключалась в том, что ветвь по умолчанию в нашей системе всегда будет копией кода на работающем сервере, при условии, что мы запомнили тягу перед запуском новой ветки. При запуске новой функции мы бы:
hg pull -b default #synch up
hg update default
hg branch {newFeature} #newFeature completely isolated from other changes.
*work on {newFeature}
О нет! Жук! это не связано с тем, над чем я сейчас работаю, давайте назовем это {bugFix111}. Это, кажется, требует новой ветки, независимой от моей функции; вернуться к обновленным значениям по умолчанию. Это изолирует newFeature и bugFix111 друг от друга, и каждый из них может работать независимо, поскольку они основаны по умолчанию.
hg update default
hg pull -u
hg branch {bugFix111}
Как только работа будет завершена, скажем, {bugFix111}
hg push -F {bugFix111} #send our fix to the main central repo on dev.
Перейти к приемке:
hg pull -b {bugFix111} #pull the fix from the central repo (dev).
hg merge {bugFix111} #merge the code in the default QA branch.
hg commit -m "Merging {bugFix111} into default"
*QA sign off on the fix
Мы должны отказаться от принятия - по умолчанию, когда проводится QA, и выпускаем, где мы объединяем материал, когда он подписывается.
hg update release
hg merge {bugFix111} #fix is now ready to go live
hg commit -m "Merging {bugFix111} into release"
На постановке:
hg pull -b release {PATH TO ACCEPTANCE REPO}
hg merge release
hg commit -m "Merging {bugFix111} into staging default"
hg tag release{date}
*robocopy to live
*run task that pull from staging to dev so that they synch up again.
Это сработало для нас и сэкономило немного времени на развертывание, так как просто сделать робокопию стабильной ветки выпуска.
Вопросы
То, что мы заметили, это:
При объединении во второй раз при выпуске легко избежать слияния, это кажется против течения. Мы можем сломать его после того, как QA подписать.
Может заставить QA также протестировать нашу ветку релизов, но похоже на дублирование ресурса, цель - просто изолировать функции и иметь возможность отправлять их по одному .
Мы можем полностью взорвать его, объединив релиз с чем-то неправильным, например, hg merge release, когда вы по умолчанию при приемке полностью перезаписываете его.
Если мы забываем тянуть перед началом новой ветки, мы работаем не с той базой.
Мало других странностей, но это самые большие препятствия.
Я понимаю, что это длинный пост, но, надеюсь, ответы помогут другим новичкам Mercurial, таким как я, попытаться настроить достойный рабочий процесс в их компании.