Миграция на другую систему контроля версий
Собеседование:
— Какую систему контроля версий используете?
— У нас RTC, но ты привыкнешь.
У всех компаний происходят такие события, как переход на новую версию библиотеки, смена фреймворка, внедрение новых инструментов. Миграция на новую систему контроля версий случается не так часто, и застать этот период может быть интересно.
Так получилось, что на новом месте работы использовалась IBM Rational Team Concert или RTC. RTC является централизованной системой контроля версий. Лицензия на RTC подходила к концу, программисты пускали слюни на git. После обсуждений все-таки было принято решение перейти на git. И пока коллеги рассматривали все за и против между использованием rebase и merge команд, я решала написать об опыте перехода с RTC на git .
Хочу сразу уточнить по особенностями организации кода: компонентная архитектура. Компоненты немного упростили нам процесс миграции. Каждый компонент лежит в своём репозитории, которые размещены на одном сервере.
Миграция идёт поэтапно
1) Создаётся репозиторий в git для компонента.
2) В новый репозиторий переносятся текущие коммиты (без остановки процесса разработки).
3) Разработка останавливается только для финальной миграции: команда получала уведомление, до какого числа старый репозиторий будет доступен для изменений. Далее репозиторий блокировался, чтобы перенести все свежие изменения в новый git-репозиторий. Делалось несколько пробных билдов, и если все хорошо, то новый репозиторий был готов к работе. Этот этап как правило занимал не более рабочего дня, иногда всего пару часов. Нашей команде за день выполнили миграцию пяти компонентов.
Сохранение истории коммитов
Важным моментом было то, что мы сохранили всю историю разработки. В самом начале обсуждений это было одно из главных требований миграции. Ранее при разработке часто возникали ситуации, что «загадочный код» был добавлен в 2012 году. В общем, классическая ситуация, это был год перехода с ClearCase (предыдущей системы контроля версий, кстати тоже от компании IBM) .
Сохранить историю изменений помогла тула с открытым кодом Tool to migrate from IBM RTC to Git.
Если честно, я была приятно удивлена, что не нужно изобретать велосипед, и для IBM RTC было уже вполне готовое решение. Для более попсовых систем контроля версия, например, SVN, такие вспомогательные тулы для миграции тоже есть SVN2Git.
Обучение сотрудников
Технические нюансы из-за миграции на git были, доработали RTC2Git для интеграции с нашей инфраструктурой, но особое внимание пришлось уделить обучению сотрудников. Были сотрудники, которые никогда не работали с git и им не сразу была понятна концепция работы с распределенными системами контроля версий. Мы организовывали внутреннее обучение, некоторых сотрудников отправляли на курсы. Также были подготовлены шпаргалки со списком git-команд.
Плюсы после миграции на git
1) Git — распределения система контроля версий
Коммиты можно делать, даже если удалённый сервер не доступен. Мы иногда сталкивались с проблемой, что репозиторий RTC был недоступен из-за упавшей инфраструктуры, но разработка не останавливались. Локально копились изменения, которые нельзя было закоммитить. Это достаточно неудобно, даже если сервер недоступен в течение нескольких часов.
2) В Git достаточно умный merge
В RTC мерж-конфликт возникал, если есть хоть какие-то изменения в локальных и удалённых файлах. Изменения не обязательно были в тех же строках, поэтому мержить приходилось абсолютно всегда вручную.
3) Быстрое переключение веток
Хоть архитектура проекта состояла из компонентов, переключение веток в репозиториях было ощутимо медленным в RTC.
4) Хорошая документированность Git
При работе с RTC часто возникали вопросы «как это сделать?», ответ на который так просто не нагуглишь и приходилось искать специфичные знания у коллег. Как по мне, у RTC порог вхождения выше. Для git искать ответы проще и быстрее.
5) Многие разработчики любят и ценят git. Когда разработчиков спрашивали, что им не нравится в работе, RTC входил в топ-10 ответов на этот вопрос.
Ну и на собеседованиях теперь не нужно было говорить «У нас RTC, но ты привыкнешь».
Полный переход на git был выполнен за два релиза, то есть пол года. Это с учётом того, что у DevOps были и другие задачи.
Спасибо за внимание и желаю поменьше мерж-конфликтов!
