Хотите дальше читать devby? 📝
Support us

Git как альтернатива Subversion

Оставить комментарий
Git как альтернатива Subversion
В посте корпоративного блога, перевод которого идёт ниже, один из основных разработчиков Digg весьма эмоционально описывает свои впечатления от перехода от Subversion к Git и рассказывает о том насколько увеличилась продуктивность команды данного проекта. За последние 12-16 месяцев в ряды команды Digg серьёзно расширились. Инженерный отдел увеличился в целых три раза, а к нему добавились ещё и отдельные QA и R&D команды. Если раньше мы выпускали код раз в три-четыре месяца, то сейчас релизы выходят фактически ежедневно. Мы столкнулись с рядом препятствий в этот переходный период, некоторые удалось легко преодолеть, решение других же далось с трудом. Нам пришлось изменить некоторые из наших процессов, освоить новые технологий, и многое изменить в менталитете наших разработчиков. Когда я начинал работать в Digg, вся наша команда девелоперов работала вместе над одним проектом – время от времени все собирались на день или два в конференц-зале, искали и фиксили баги, после чего выпускался релиз, и команда переключалась на следующий проект. Сейчас же мы ведём разработку сразу нескольких проектов параллельно, и каждая функция создаваемого решения проходит проверку QA отделом, после чего она и выходит в свет. Вначале мы использовали Subversion. Мы проверяли, разветвляли, коммитили, сливали и тэгировали. Это было далеко от совершенства и не сильно всех радовало, но это то, что у нас было. И это работало, в основном. Это была простая для понимания система и очень проста в использовании. Но только до определённых масштабов. Наша инженерная группа росла, все больше и больше работы делалось в одной и той же баз кода, и всё чаще мы мешали и, так сказать, наступали на ноги друг другу. Процесс интеграции (объединения функций для релиза) длился по несколько дней и приводил к появлению множества конфликтов в коде. Человек, который осуществлял сборку, пытался разобраться самостоятельно с проблемой или же обращался к девелоперу, непосредственно реализовывавшему какую-либо функцию, чтобы отследить, в чём именно конфликт и какой код следует править, а какой сохранить. Всё это в обоих случаях приводило к множеству багов, а также буквально к исчезновению части кода. И это стоило нам времени, денег и влияло на наших пользователей, а ко всему этому мы относимся всегда серьёзно. Мы знали, что должен быть какой-то другой, лучший, путь и стали его искать. Сначала мы пытались перейти от Subversion 1.4 к 1.5, в котором есть функция отслеживания сборок. Мы надеялись, что она сделает наш процесс интеграции куда более простым. Однако после того как мы поработали с Subversion 1.5 несколько недель мы поняли, что “merge tracking” в данном случае скорее миф нежели реальность. В теории всё хорошо, а на практике – толку ноль.

И тут пришёл Git

Тогда все заговорили о Git. Некоторые из нас слышали о нём, и только пара человек вообще в глаза видела и использовала, но в основном только для своих личных проектов. Оказалось, что Git - это будет next big thing, потому что он действительно очень и очень крутой. Жизнь наших инженеров стала куда проще, а сами они гораздо продуктивнее. Это был словно стакан холодного лимонада в жаркий день. Мы сделал один осторожный глоток – вкус напитка оказался весьма неплохим, потом второй, а потом с удовольствием одним махом осушили весь стакан. Так чем же Git так замечателен? Ну, в двух словах, просто потому что он мощный и распределённый. Он позволяет решать сложные задачи в несколько команд. Он делает такие вещи, как ветвление и сборка практически полностью бездумным и ненапряжным. Он фактически позволяет вам переписывать историю. Это действительно позволяет каждому инженеру работать так, как они хотят. И когда они готовы, выпускать свой код на всеобщее рассмотрение. Управление кодом и changeset'ами здесь так резко отличаются от Subversion, что это приводит прямо таки к ментальному сдвигу, и вы, наконец, начинаете понимать, что вообще такое система управления версиями. И поверьте мне, это круто. Но есть у Git и свои недостатки. Сначала может будет трудно понять, что действительно происходит за кулисами, когда вы запускаете команду, и если что-то пойдет не так, вы действительно должны понимать, как Git работает изнутри, чтобы исправить свою ошибку. Он также ещё не конца отполирован, у него нет хорошего графического интерфейса, и выдаваемые сообщения об ошибках, вы получаете, когда команде не удается выполнить операцию, вполне могут быть написаны на санскрите. Но, несмотря на всё это, он работает. И работает так, что после перехода на Git, нам удалось сократить время на интеграцию от нескольких дней до нескольких минут. Буквально с 1-2 дней до примерно 30 минут. И после интеграции у нас теперь куда больше уверенности в том, что сборка осуществлено правильно. Мы также теперь в состоянии выпускать код на ежедневной основе с минимальными усилиями, что было очень тяжело сделать, используя с Subversion. Оригинал
Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.

Читайте также
Состоялся первый публичный релиз децентрализованной платформы совместной разработки Radicle
Состоялся первый публичный релиз децентрализованной платформы совместной разработки Radicle
Состоялся первый публичный релиз децентрализованной платформы совместной разработки Radicle
GitHub представил программу сертификации для разработчиков
GitHub представил программу сертификации для разработчиков
GitHub представил программу сертификации для разработчиков
Хакер стирает Git-репозитории и требует выкуп
Хакер стирает Git-репозитории и требует выкуп
Хакер стирает Git-репозитории и требует выкуп
Уязвимости в Git позволяют удалённо выполнять код
Уязвимости в Git позволяют удалённо выполнять код
Уязвимости в Git позволяют удалённо выполнять код

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.