Собеседование:
- Какую систему контроля версий используете?
- У нас 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 были и другие задачи.
Спасибо за внимание и желаю поменьше мерж-конфликтов!
Комментарии (31)
dashanddot
23.06.2024 08:04git создан для опенсорс разработки, для всего остального он совершенно не годен. используйте свн, он умеет делать все тоже самое что и гит. открою секрет можно сделать клн репо у себя на компе и тоже будут локальные камиты
maisvendoo
23.06.2024 08:04+7Чем же, позвольте полюбопытствовать, опенсорц разработка так принципиально отличается от "всего остального"?
aeder
23.06.2024 08:04+1Концепция гит: куча ветвей, сделанная программистами неизвестного качества, которые интегрирует в мастер-ветвь гуру продукта. В принципе, неплохо ложиться на процесс разработки в компании, которые постоянно нанимают джунов, немного их эксплуатируют и заменяют на новых. Плохо ложиться на организацию, которая нанимает опытных программистов, в случае, когда над отдельным подпродуктом работает 1-2 программиста максимум.
Распределённая разработка в гит не имеет особого смысла для корпоративного применения (скорее, опасна и неудобна для корпораций), но очень востребована в опенсоурсе.
Концепция гит: один репозитарий - один продукт. Ветвление репозитария целиком. Отлично подходит для опенсоурсной разработки, но в корпоративной среде возникают проблемы с зависимостями: продукты не являются независимыми. Т.е. крупные организации очень редко разрабатывают самодостаточный продукт, использующий только "чужие" библиотеки. Обычно он состоит их кучи библиотек и кучи экзешников, каждый из которых - отдельные подпродукты с собственным циклом выпуска релизов. В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях.
Гит может работать с бинарными файлами. Но - всегда криво и с косяками, с дополнительными нашлёпками.
В общем и целом, гит отлично подходит для компаний, чьи разработки не требуют системы управления конфигурации (сonfiguration management).
Т.е. если версия вашего продукта "живёт" полгода, релизы выпускаются часто-часто, долгосрочной поддержки нет, цена ошибки низкая - гит для этого отлично подходит.
Отлично гит подходит для веб-разработки, когда конечный продукт вы же и поддерживаете (т.е. предоставляете доступ к своему хостингу, но не даёте клиенту автономный хостинг).
Если ваш цикл технической поддержки продукта - десятилетия, если продукты сложные и взаимно-зависимые, если вам в любой момент может понадобиться точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик, и вы не можете заставить заказчика обновиться на текущую версию продукта, потому что обновление стоит очень больших ресурсов, если вместе с продуктом вы разрабатываете документацию в разных форматах (бинарных форматах редакторов и CADов) - гит не для вас.
С моей точки зрения, идеальной системой управления версиями была бы централизованная система с кластером серверов, похожая на Perforce или SVN, но с возможностью выделять/маркировать отдельные папки/подпродукты/каталоги так, чтобы слияние изменений можно было выполнять только на папку целиком.
DarthVictor
23.06.2024 08:04+2Если ваш цикл технической поддержки продукта - десятилетия, если продукты сложные и взаимно-зависимые, если вам в любой момент может понадобиться точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик, и вы не можете заставить заказчика обновиться на текущую версию продукта, потому что обновление стоит очень больших ресурсов, если вместе с продуктом вы разрабатываете документацию в разных форматах (бинарных форматах редакторов и CADов) - гит не для вас.
Назовите пожалуйства нормальные системы контроля версий, работающие с бинарными файлами. И как в таких системах выглядит просмотр изменений между файлами. И частичное применение изменений заодно.
aeder
23.06.2024 08:04+1Perforce, например. Разумеется, изменения в бинарных файлах произвольного типа просмотреть/объединить сама система не может (точнее, может для ограниченного количества форматов, в основном картинки) - но если есть внешние средства - можно использовать их.
При этом, например, хранение проектной документации в том же Word/Autocad/Visio - запросто. Одна возможность хранить историю изменений бинарных файлов (и сами файлы) - это уже очень много.
DarthVictor
23.06.2024 08:04+1А в чём разница с гитом?
aeder
23.06.2024 08:04Ну например, выложив в Perforce бинарный файл (который не получиться смержить) вы сможете поставить ему тип "binary+l". Так как Perforce - система централизованная, после этого данный файл сможет редактировать только один человек за один раз. Соответственно, необходимости "сливать" конкурентные изменения - не будет.
Разумеется, скорее всего для git можно сколхозить что-то подобное. Или использовать отдельную систему "управления документацией" - но это, как надеюсь вы понимаете, набор из резиновых костылей.
Ещё раз - в git можно сделать всё. Но предназначен git для специфической модели разработки и специфических целей - как только вы пытаетесь его приспособить за пределы его исходной концепции - получается хреново.
Кстати, с этой точки зрения точно то же самое и в Perforce. Разрабатывать классический опенсоурсный продукт в Perforce - с получением патчей от неопределённого круга лиц, с разработчиками работающими независимо и самостоятельно - ну, больше всего похоже на мазохизм.
DarthVictor
23.06.2024 08:04Так как Perforce - система централизованная, после этого данный файл сможет редактировать только один человек за один раз.
Вообще с моей точки зрения блокирование одновременной работы - это само по себе один большой костыль.
Но предназначен git для специфической модели разработки и специфических целей - как только вы пытаетесь его приспособить за пределы его исходной концепции - получается хреново.
Под эту концепцию вполне попадает процентов восемдесят современной разработки ПО.
randomsimplenumber
23.06.2024 08:04точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик,
А в чем проблема то? В этом вашем git через полгода коммиты превращаются в тыкву? Или никто не знает как пролистать историю на 10 лет назад?
В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях
Ну, субмодули, например. Не слышали? :)
aeder
23.06.2024 08:04Слышали и пробовали. Не работает в качестве системы управления конфигурацией.
randomsimplenumber
23.06.2024 08:04Ну, может ваша система не на файлах построена, а как то иначе. У всех прочих работает.
unreal_undead2
23.06.2024 08:04В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях.
Это проблемы билдовой системы, в которой расписываются зависимости между версиями подпродуктов и откуда их брать - в общем случае разные подпродукты могут лежать в разных системах контроля версий.
VanKrock
23.06.2024 08:04+1Какие-то странные аргументы, куча компаний использует гит и радуется жизни, вспоминают svn и mercurial как страшный сон. Гит в первую очередь даёт свободу команде, она сама ведёт свой проект и сама выбирает как будет синхронизароваться с другими проектами, как правило для этого есть контракты иного уровня. Так же что делать если вы вдруг решили вывести часть своих библиотек в open source? А для решения приведённых вами проблем есть монорепозитории, гит модули и иные средства гита для синхронизации кода между проектам. Гит стал практически стандартом разработки не просто так.
ALexhha
23.06.2024 08:04Ага, svn сервер не доступен и приехали. Разработка стала. Так по корпоротивному
randomsimplenumber
23.06.2024 08:04Так разработка это не только в vim код херячить. gitlab/jenkins/файлопомойка/любой компонент отвалится - разработка стала.
ALexhha
23.06.2024 08:04Так разработка это не только в vim код херячить. gitlab/jenkins/файлопомойка/любой компонент отвалится - разработка стала.
Что мешает писать код локально, пока что то из этого недоступно ? Мы же не рассматриваем цикл CI/CD, а лишь написание кода. В случае с svn даже историю изменений локально не получится сохранить
Aquahawk
За 15 лет разработки наблюдал две миграции, svn->mercurial, mercurial->git. По опыту разработчики быстро делятся на две фракции, кто прочитал официальную документацию, и им всё понятно и работают они с системой контроля версий через консоль, и тех кто поставил какой-то gui tool, не читал документацию, пытается применять подходы из старой системы контроля версий в новой. По факту же даже между git и mercurial есть значительные различия, не говоря уже о том что в svn существовали подходы которые в новых системах крайне неудобны (например частичный мердж подпапок и ветвление тоже подпапок а не всей репы). Короче важно как-то сделать так чтобы побольше людей глубоко прониклось новой системой контроля версий, изучили доки, и тогда новые подходы будут выработаны быстро и эффективно.
aamonster
Ага. Mercurial – система контроля версий, git – конструктор для сборки системы контроля версий :-)
Aquahawk
ну типа того. Хотя супер наполенный контентом проект у нас так и сидел на svn, проигнорировав миграцию на hg. А с гитом ребята хорошо изучили вопрос, перестроили workflow и всё стало ок, только вместо одной svn репы, стало 8, как раз из-за мерджа отдельных кусков проекта
aamonster
Прикольно. Для меня выглядит так, будто вы попали на тот редкий случай, когда конструктор удобнее готового решения.
У меня при пользовании гитом в основном подгорает из-за отсутствия полноценных веток (указатель на голову ветки – это немного не то, он не позволяет увидеть, какие коммиты делались в эту ветку, а какие пришли со стороны).
Ну и, конечно, поначалу бесило отсутствие "святости истории" (очень быстро пришлось освоить git reflog) и то, что pull/push не обрабатывают все ветки.
Но в целом git – стандарт де-факто, в случае отсутствия каких-то фатальных проблем нет резона использовать другую vcs.
Aquahawk
ну там примерно полмиллиона файлов в том гите, так что да, нестандартно. А про ветки вы очень верно подметили, да в гите именно указатели на головы и всё.
Aquahawk
кстати, у нас да, алиасов понаписано много, и отдельно бесит что нельзя простым образом гитконфиг просунуть через ssh как ключи, на произвольнос сервере без алиасов чувствуешь как будто в каменный век попал, всё руками набирать, тот же git submodule update —init —recursive просто неимоверно бесит, у меня это алиас git sup.
ManGegenMann
Ну это я. Зачем мне перхдохаться в консоль? Я через гуй раза в 10 быстрее делаю то что мои красноглазые калеги там в консоли дергают.
randomsimplenumber
А что они такое медленное делают в консоли?
polearnik
слияние, поиск в истории, работа с ветками .
randomsimplenumber
А почему так медленно то? И штож вы не сказали им что есть способ сделать это в 10 раз быстрее?
polearnik
в моей команде ребята только на сервере используют в консоле команды клонирования и затягивания обновлений на тех проектах которые еще не в дженкинсе а на локалке все поголовно используют гуи .
VanKrock
тот же abort merge делать в консоли или в Rider, в райдере это одну кнопку нажать