Как поощрять принятие контроля версий

21

Я недавно начал работать в команде, где нет контроля версий. Большинство членов команды не привыкли к контролю версий. Я использовал Mercurial в частном порядке, чтобы отслеживать свою работу. Я хотел бы призвать других принять его и, по крайней мере, начать создавать версии своего кода по мере развития изменений. Может ли кто-нибудь дать мне совет о том, как я могу поощрять принятие распределенного контроля версий, такого как Mercurial. Любой совет о том, как привлечь людей, в том числе менеджеров в DVCS, будет принята с благодарностью.

Man Wa Kileleshwa
источник
4
Я бы добавил ответ, но не могу. Я потерял дар речи (или, скорее, не типизирован). С момента появления SCCS прошло уже почти 40 лет. Существуют ли еще организации, которые не используют контроль версий ни для чего, кроме простейших проектов? (В настоящее время это другая крайность; некоторые люди имеют свой домашний каталог в качестве хранилища git.)
Дэвид Хаммен
11
Не поощряйте это; требовать его.
Стивен Эверс
1
Компания, с которой я сейчас работаю, консультируется с гораздо более крупными компаниями, чем мы, и мне еще предстоит столкнуться с компанией, использующей контроль источников ... Подумав об этом утверждении, я внезапно понимаю, почему им нужен кто-то другой, чтобы решить свою проблему. Первое, что мы обычно делаем, - это требуем, чтобы они настроили его, чтобы мы могли использовать его для интеграции и управления своими и нашими изменениями. Как заявил @SnOrfus, требуйте этого. Вы также можете указать на всю документацию, в которой она отмечена как лучшая практика.
Джошуа Дейл
7
Я со SnOrfus. Есть некоторые хорошие ответы здесь, но в конечном счете, если вы не получите положительную реакцию сразу же , пришло время идти. Как и Дэвид Хаммен, я потерял дар речи, что в 2011 году любой разработчик находится в ситуации, когда ему необходимо решить такую ​​проблему, как эта. Отсутствие контроля версий является дисфункцией, которая просто недопустима.
Carson63000
2
Пробирайся за одну ночь и удаляй свои жесткие диски. Нет простите. Временного упадка профессионализма нет.
DJClayworth

Ответы:

7

Вы должны обосновать необходимость использования контроля версий и сначала попытаться продать его своим коллегам, а если это не удастся, подняться по цепочке к руководству проектом и выше.

Для коллег-разработчиков программного обеспечения ваше дело должно быть сосредоточено на том, как он экономит время и избавляет от головной боли в долгосрочной перспективе. Найдите время из своего прошлого или опубликованных историй (блоги, статьи в журналах, официальные документы) о том, как использование контроля версий облегчает вашу жизнь. Если вы сгорели из-за отсутствия контроля версий, сделайте его личным. Если ваши коллеги-разработчики оказались в такой же ситуации, они должны увидеть свет и то, как эти инструменты могут им помочь.

Это ваша лучшая ставка. Хотя я не могу найти источник (источники) прямо сейчас, я прочитал (в нескольких местах), что наиболее эффективные изменения в процессе происходят от разработчиков, которым приходится иметь дело с изменениями. Если вы сможете привлечь разработчиков к работе, вы достигнете двух вещей. Во-первых, у вас уже есть вступительный взнос от людей, на которых повлияет изменение процесса. Во-вторых, есть группа людей, которые убеждают руководство в том, что это стоит усилий и улучшит продукт и проект.

Однако, если вы не можете получить поддержку команды разработчиков и по-прежнему испытываете сильные чувства к развертыванию системы контроля версий, вы можете перейти к управлению. Но это становится более рискованным, если вы идете в одиночку, так как вам нужно не только беспокоиться о продаже улучшения, но также иметь дело с обратной реакцией со стороны ваших коллег.

Для управления проектами, программами и организацией необходимо учитывать, как развертывание системы контроля версий может сэкономить время и деньги организации. Люди на этом уровне заботятся о том, сколько денег стоит проект, где он стоит по сравнению с оценками и так далее. Ищите технические документы, книги, статьи и другие профессиональные документы и публикации, которые объясняют, как развертывание контроля версий сэкономило время и деньги других организаций в долгосрочной перспективе. Вы также можете представить здесь перспективу качества, если ваша организация заинтересована в качестве программного обеспечения.

Вы специально упомянули, что хотите использовать распределенную систему контроля версий. Не заставляйте это глотать команду или организацию. Познакомьте их с контролем версий и их опциями. Хотя вы лично предпочитаете использовать DVCS (например, Mercurial), он может не подходить для вашей команды и организации. Использование инструмента, который не подходит, только усугубит ситуацию с молотилкой.

Также следует помнить о рисках, связанных с запоздалым внедрением процесса . Хотя использование контроля версий является общепринятой передовой практикой, было бы слишком поздно эффективно внедрять его в текущий проект без огромного риска его завершения. Вместо этого я бы рекомендовал сосредоточиться на улучшении статус-кво для будущих проектов и команд.

Кроме того, это общий подход, который вы можете использовать для выполнения любых технологических или технологических улучшений.

Томас Оуэнс
источник
5

Первый вопрос: что они делают в настоящее время? Конечно, у каждого разработчика нет исходного кода, прикрепленного к его собственной коробке, которую он изменяет по своему желанию. Если у вас есть процесс, которому они в настоящее время следуют, вы можете предложить некоторые инструменты, которые улучшают этот процесс - обычно SCM идеально подходит, чтобы помочь им в этом, а не заставлять их следовать другому процессу.

Суть в том, что если у них есть псевдо-SCM способ работы, возможно, где-то хранится текущая версия на сервере, тогда вам нужно определить, подходит ли DVCS или CVS, не пытайтесь продавать их Mercurial. если SVN лучше подходит.

gbjbaanb
источник
3

Самый быстрый способ - убедить руководство в том, что оно необходимо.

Сделайте некоторые расчеты:

Стоимость программного обеспечения для контроля версий - бесплатно.
Стоимость оборудования для поддержки хранилища - один сервер.
Стоимость внедрения программного обеспечения - пара человеко-дней для небольшой команды, растущая для более крупных команд.

Стоимость не реализации контроля версий:

В лучшем случае - потерянные дни из-за пропущенных правок, перезаписи изменений друг друга и т. Д., Повторяющихся ошибок и т. Д.
В худшем случае - сколько бы человек ни сил приложил к этому времени.

Этот последний показатель является наихудшим сценарием, когда вы теряете всю работу из-за сбоя сервера и т. Д., Но даже сценарии «наилучшего случая» должны объяснить им, почему это необходимо. Стоимость повторяющихся ошибок может быть выше, поскольку это может привести к потере клиентов.

Команда разработчиков также должна понимать эти затраты, и учитывая, что большинство (если не все) программ управления версиями в настоящее время легко интегрируются с IDE, они даже не заметят, что они там большую часть времени.

ChrisF
источник
Стоимость программного обеспечения для контроля версий не является бесплатной. Само программное обеспечение может быть бесплатным (в зависимости от вашего выбора), но в организации, у которой ничего нет, вам нужно обучение для инженеров, вам может потребоваться аппаратное обеспечение для репозиториев, и если организация предоставит его всем, увеличение финансирования ИТ для поддержки новых требований к аппаратному и программному обеспечению. Не говоря уже о высоком риске развертывания процесса в конце проекта.
Томас Оуэнс
@Thomas - отсюда и мое мнение о стоимости его реализации (что, вероятно, занижено)
ChrisF
Редактирование делает это намного лучше.
Томас Оуэнс
1

Менеджмент обычно заботится о том, чтобы сэкономить деньги. Подчеркните, как контроль версий может принести пользу команде в финансовом отношении, и вы сразу же привлечете их внимание!

rrazd
источник
Управление делает, но всегда легче привлечь внимание руководства, если у вас есть группа людей, которая говорит что-то, а не человек.
Томас Оуэнс
@Tommas действительно, больше голосов создает больше шума и, следовательно, более вероятно, чтобы привлечь внимание руководства
razd
1

Есть один аспект, который другие люди здесь не затронули, и я думаю, что вы находитесь в своем углу - вы говорите о распределенном контроле версий - по самой своей природе, вы можете использовать это в практике, один разработчик вовремя. С более жестким контролем версий, таким как то, что мы используем в моем офисе (MS Visual SourceSafe), вам будет трудно подойти к парню в кубе напротив моего и продать его, один на один, за заслуги контроль версий. Тем не менее, с (любой) DVCS, вы можете просто сказать «эй, попробуйте это, и посмотрите, если вам это нравится. Я покажу вам веревки, и я был бы рад ответить на любые вопросы, проведу вас через, бла-бла бла». Таким образом, вам не нужен «процесс» сверху вниз, вы можете создать мандат на низовом уровне, по одному человеку за раз.

Nate
источник
0

Опираясь на ответ Гбйбаанба.

Ключевым моментом здесь является то, что вы должны адаптировать процесс управления версиями к любому существующему процессу и показать, как он экономит оставшиеся командные усилия.

Я лично также предпочитаю Mercurial, но не обязательно навязывать его людям, не привыкшим к управлению версиями, потому что это немного сложнее понять, чем старомодная серверная система контроля версий с блокировкой версий. Тем не менее, если это настоящий сайт с зелеными полями, может быть, лучше всего пойти на свиней, пропустить 80-х и 90-х годов и перейти на Mercurial. Я также хотел бы взглянуть на некоторые сторонние программы жизненного цикла, построенные на Mercurial - я уверен, что есть один, но его имя ускользает от меня;)

Я предполагаю, что вы работаете в небольшой компании и что вы относительно новичок в команде, так что это может быть трудно продать, особенно если остальная часть команды укреплена и пользуется доверием руководства. Лучше всего дать им что-нибудь плохо и потом прийти на помощь. Это не означает саботаж, просто жди неизбежного.

mcottle
источник
Спасибо за все ваши ответы, можно ли сделать этот вопрос вопросом сообщества? Сила, которая позволяет мне дать краткий доклад / демонстрацию за 15 минут о том, как я ее использую. Одно препятствие - кто его использует? Это какая-то условно-бесплатная программа из интернета? Я хотел бы успокоить опасения, указав на некоторые известные компании, которые используют / поддерживают Mercurial (любой DCVS) в коммерческих целях. Может ли кто-нибудь помочь мне процитировать некоторые компании, которые используют Hg? Или другой известный продукт, использующий его. Есть сопротивление (негласные глаза) к open source, некоторые менеджеры, похоже, с подозрением относятся к программному обеспечению, за которое они не платят.
Мужчина Ва Килелешва