Количественная оценка преимуществ современной системы контроля версий [закрыто]

24

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

Первое, что я сделал, присоединившись к команде, это настроил свою команду на Git. Все согласились с тем, что Clearcase был ужасен и непрактичен для решения повседневных вопросов контроля источников. Поэтому мы установили своего рода «неофициальный» репозиторий на моем локальном компьютере, и я написал скрипт для синхронизации наших репозиториев git и Clearcase во время выпуска.

Известие об этом распространилось на другие команды, и некоторые приняли тот же процесс. Использовать git «неофициальным» способом для повседневной деятельности и «официально» использовать Clearcase для релизов. Я стал чем-то вроде парня за любые проблемы с Git.

На этой неделе у меня встреча с SVP по изменению инфраструктуры, которая специально хочет, чтобы я объяснил ей достоинства Git. Известно, что до нее дошли слухи о моих частых беспорядках в Клиркасе. Если она примет мои аргументы, я действительно помогу своему работодателю избавиться от этой мерзости.

Мой опыт работы с руководителями говорит мне, что они: а) хотят очень краткие объяснения всего, б) интересуются только фактами, которые включают цифры в долларах

Разработчику я могу объяснить преимущества Git over Clearcase (или ЛЮБОЙ другой системы контроля версий над Clearcase в этом отношении), но я рисую бланк о том, как это сделать техническому руководителю без технического образования (у нее есть MBA и сделал ее студент в области географии).

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

Я пытаюсь найти конкретные факты, демонстрирующие, что разработчики более эффективно работают с Git или ЛЮБОЙ современной системой контроля версий.

Я думаю, что тот факт, что другие команды начали использовать Git для внутреннего использования, является значимым признаком, но он все еще недостаточно силен, поскольку его все равно можно отрицать как личное предпочтение.

Что мне действительно нужно, так это что-то достаточно мощное, чтобы прорваться через «Этот процесс работал в течение 20 лет, зачем нам его менять?» аргумент.

Майк
источник
4
Я думаю, что вы судите их, если думаете, что их интересуют только факты с цифрами в долларах. И они могли бы хотеть кратких объяснений, потому что подробное объяснение может обмануть их во что-то, что они не понимают. Наилучшим подходом, возможно, является выдача списка хороших вещей, которые есть у Git, а у ClearCase нет. Тем не менее, я чувствую, что руководители корпоративной среды не доверяют программному обеспечению с открытым исходным кодом, особенно если существует хорошо известная корпоративная версия.
InformedA
8
рекомендуемое чтение: как я могу объяснить $ {что-то} $ {кому-то}?
комнат
2
Продемонстрируйте, насколько больше использование git делает вас (и другие команды) эффективными в выполнении ваших обязанностей. Не добровольно заменяйте ClearCase, не выслушав его, но покажите, где находятся повседневные преимущества. ClearCase может потребоваться для аудита сборки или отслеживания проблем всего проекта, в котором Github не силен.
Кевин
3
Если они заинтересованы в долларах, покажите им ежегодные лицензионные сборы ClearCase и сотрудников, которых вы должны заплатить, чтобы их обслуживать.
17 из 26
3
«приостановить как основанное на мнении», я с этим очень не согласен. Из моего вопроса «Что я пытаюсь найти, так это конкретные факты, демонстрирующие, что разработчики работают с Git более эффективно». На чем основано мнение?
Майк

Ответы:

22

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

Вы говорите: «Этот процесс работал в течение 20 лет», но так ли это? Начните с обрисовки того, что вы подразумеваете под "нашим производственным процессом - это кошмар". Создайте список проблем с текущим процессом / инструментом, который является максимально независимым от ClearCase.

Затем создайте список «решений» процессов / инструментов, которые настолько независимы от Git, насколько это возможно (хотя Git или любая современная DVCS точно подойдут). Объяснение, почему Git лучше, чем ClearCase, ничего не значит для не пользователей.

Позвольте команде по инфраструктуре подтвердить, что текущий подход имеет проблемы, которые вы идентифицируете. Это, вероятно, приведет к тому, что они обратятся за поддержкой в ​​IBM, чтобы «исправить» эти проблемы. Оставайтесь на связи, чтобы гарантировать, что IBM не решит проблемы. Поскольку в ClearCase отсутствуют основные свойства нашего современного понимания управления версиями, большинство из этих проблем не может быть исправлено или потребует существенного изменения инфраструктуры.

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

Удачи!

Джейс Браунинг
источник
Примечание: ClearCase не 20 лет.
Ян Худек
2
Я не думаю, что вы найдете что-то, что не может быть сделано с ClearCase. Но многие вещи будут намного сложнее с ClearCase и, что еще важнее, медленнее, чем патока . К счастью, быстрое выполнение работы - это аргумент, который принимает большинство менеджеров .
Ян Худек
10
@JanHudec первый выпуск Rational ClearCase был в 1992 году, ему исполнилось 22 года.
private_meta
@private_meta: Хм, не знаю, почему я вспомнил 1998 год.
Ян Худек
14

Наш производственный релиз - это кошмар, потому что он вращается вокруг Clearcase. У нас есть группа управления изменениями, которая выполняет все выпуски и которая разрешает только код в производство, который был взят из него.

Нет, ваш процесс "кошмарный" из-за вашей группы управления изменениями и ваших процедур выпуска. Идите вперед и замените Clearcase на SVN или git или Fossil. У вас будут точно такие же проблемы . (Я думаю, что они делают это правильно, ТБХ, строгий контроль выпуска важен).

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

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


Несколько идей для вас: пусть они увидят проблемы производительности с текущей системой с точки зрения разработчика. Сделайте это как часть 1 из 2. Часть 2, поработайте с ними над выпуском, чтобы вы могли увидеть проблемы управления, которые должны понять ваши разработчики. Рассматривайте это как учебное упражнение для обеих сторон, чтобы увидеть мнение другой стороны, и тогда вы сможете лучше найти решение, которое по-прежнему решает основные требования, которые есть у любой из сторон. Обратите внимание, что релизы более важны, чем dev, поэтому вы должны быть готовы дать больше, чем вы ожидаете.

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

gbjbaanb
источник
Ну, может быть, самая большая проблема с ClearCase в том, что он медленный, как патока. Поэтому, если процесс сложный (и для этого может быть веская причина), переключение на что-то более быстрое улучшило бы его.
Ян Худек
1
@JanHudec Я помню, что Clearcase ... это было не так медленно, когда я работал, но, возможно, это один из тех продуктов, где репо помещается на сервер в удаленном корпоративном центре обработки данных, окруженном множеством уровней безопасности и маршрутизации. Я думаю, что у OP будет больше шансов с SVN или TFS, чем с git, но это не то, на что он рассчитывает.
gbjbaanb
3
ClearCase - это в основном сетевая файловая система с управлением версиями. Так что пропускная способность сети и особенно задержка имеют для нее большое значение. С локальной репликой большинство операций было терпимо (но все же намного медленнее, чем в git, который рассчитан на скорость), но некоторые операции были ужасными. Худшее, что я сделал, это пометил все файлы для выпуска, что заняло 15 минут, и это был не очень большой проект.
Ян Худек
1
+1 за указание на то, что это проблема людей, а не технологическая проблема.
kdgregory
1
Самым большим кошмаром, который у меня был с clearcase, было то, что, как и CVS, он работал только на уровне отдельных файлов; Это означает, что проблемы слияния / etc приведут к тому, что новейшая версия в CC станет неработающей сборкой и невозможностью откатить всю кодовую базу до произвольной даты / времени. Использование опции для локального просмотра вместо виртуального сетевого диска значительно уменьшило задержку ввода-вывода.
Дэн Нили,
6

Конкретные примеры будут впечатлять больше, чем абстрактные преимущества. Я думаю, вы добьетесь наибольшего успеха, если сможете документировать конкретные примеры, в которых (a) Clearcase вызывал проблемы, на решение которых потребовалось время, и (b) Git решает эти проблемы. Помните, что вам не нужно вдаваться в технические детали того, почему это так (если не спросить), просто покажите, что это так; руководству не нужно знать технические детали, за это вам и платят.

Если вы можете приложить конкретные сроки и даты к этим примерам, тем лучше. Вы также можете завершить это, показав, что задача X, которую вы выполняете, занимает Y минут в Clearcase и Z минут в Git.

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

Джек Эйдли
источник
3

Вот попытка того, как я это попробую.

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

«Если волшебная штуковина уже работает, зачем рисковать, чтобы сломать ее?»

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

Я бы начал с того, что git сейчас широко используется. Используйте числа, например: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

Для менеджера это означает, что они должны быть в состоянии найти множество разработчиков, использующих git. И целая экосистема сторонних инструментов (я слышал, что даже Microsoft теперь интегрирует git с visual studio).

Кроме того, менеджер не может быть обвинен в том, что следил за основными вещами, не так ли? В отличие от этого, кто использует здесь $ other_cvs?

Делайте акцент на том, как большие проекты используют его, потому что он простой, быстрый, гибкий, мощный ... Найдите крупные проекты с громкими именами (GNU / Linux, Google, Microsoft ...), которые используют git.

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

Вы хотите, чтобы компания оставалась конкурентоспособной и не опережала более быстрые и гибкие команды? Я бы попытался найти некоторые внутренние (письменные) оценки того, как производительность изменилась с помощью Clearcase vs Git. Вы можете использовать некоторую помощь от ваших коллег-разработчиков. Затем выполните экстраполяцию для всей компании (т. Е. Для всех разработчиков программного обеспечения) с указанием чисел и предполагаемой стоимости пребывания в Clearcase.

Я бы даже, в случае необходимости, подытожил бы все это в письменном электронном письме после встречи (включая нужных людей).

Nha
источник
1
Если у них есть специальный отдел релизов, они почти наверняка не поймут, что такое «более быстрые и гибкие команды». Они, вероятно, также не заботятся о производительности разработчиков. Они позаботятся о надежности, отслеживаемости изменений и контроле того, что в итоге выйдет.
gbjbaanb
@gbjbaanb хорошая мысль, однако я не видел, как спорить об этом в беседе с менеджером, когда уже используется другой CVS.
ня,
1

Что мне действительно нужно, так это что-то достаточно мощное, чтобы прорваться через «Этот процесс работал в течение 20 лет, зачем нам его менять?» аргумент.

Это неверный аргумент (конные экипажи «работали веками», но вы, вероятно, хотите купить автомобиль).

Я слышал тот же аргумент о svn и mercurial (именно я использовал mercurial в своей системе разработки).

Эта проблема не о замене того, что работает; Не пытайтесь сформулировать это так, и если это вопрос, который вам нужно «победить», вы должны начать с указания, что дело не в том, что работает или нет, а в том, какие преимущества у вас есть с git , когда оба работают (и почему Git работает лучше).

Хорошие аргументы для использования git:

  • git ориентирован на изменения, а не на файл. Это означает, что изменения легче отслеживать по файлам (отслеживаемость по проекту).

  • мерзавец распространяется вместо централизованного; Это означает, что проверка материала не ограничена скоростью сети - опять же экономя много времени. Это также означает, что у вас нет единой точки отказа в случае отказа вашего сервера ClearCase.

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

Я думаю, что тот факт, что другие команды начали использовать Git для внутреннего использования, является значимым признаком, но он все еще недостаточно силен, поскольку его все равно можно отрицать как личное предпочтение.

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

На этой неделе у меня встреча с SVP по изменению инфраструктуры, которая специально хочет, чтобы я объяснил ей достоинства Git.

Нарисуйте диаграмму, представляющую коммиты с двумя системами, и покажите упорядочение, полученное разработчиками, не комментирующими публично (т.е. если вы создаете файл, остальная часть команды не блокируется и не может компилироваться, пока вы не исправите ее). Также объясните, какой дополнительный контроль качества вы можете выполнять, когда вы можете выполнять промежуточные коммиты, не затрагивая кого-либо еще, а также тот факт, что вы можете получать чистые различия для каждой функции (важно для проверки кода).

utnapistim
источник
3
Нетехническое руководство, вероятно, не будет заботиться об этих аргументах.
JCM
1
Проблема с приведением конкретных точек сравнения заключается в том, что вы должны очень хорошо знать альтернативы , иначе вас разорвут на части. В случае этого ответа единственно верным является пункт «распределенная или централизованная», и даже в этом случае вы должны быть готовы к тому, что «вы имеете в виду, что у каждого, возможно, недовольного сотрудника, есть весь репозиторий исходного кода на их ноутбуке?!?»
kdgregory
2
@kdgregory У каждого недовольного сотрудника также есть несколько zip-файлов и личных репозиториев кода, потому что ClearCase слишком медленный и громоздкий, чтобы работать в 100% случаев. :-)
Джейс Браунинг
@kdgregory, и они будут набрасываться на «вы можете зарегистрироваться, не отправляя его на сервер, что если ваш компьютер выйдет из строя, вы потеряете все свои проверки. Где находятся резервные копии? как мы контролируем один поток источников для создания каждого» освободить от? "
gbjbaanb
1

Что мне действительно нужно, так это что-то достаточно мощное, чтобы прорваться через «Этот процесс работал в течение 20 лет, зачем нам его менять?» аргумент.

Трудно действительно судить, что было бы хорошим аргументом, не будучи свидетелем сцены. Но я постараюсь помочь вам сформулировать ваши аргументы, чтобы они могли быть услышаны.

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

  • Какие новые возможности это принесет? Есть ли что-то, что мы в настоящее время не можем сделать, что мы хотели бы сделать, и что эта новая вещь позволит нам? Начните с положительной ноты.

  • Как это повлияет на графики выпуска? Какова стоимость внедрения этого изменения в отношении следующего выпуска? Каковы затраты и преимущества следующих выпусков?

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

  • Есть ли неизбежные опасности для придерживаться нынешней системы? Имеются ли у текущего процесса программные или аппаратные зависимости, которые ушли или скоро выйдут из строя? Это полагается на специальные знания от людей, которые увеличивают затраты найма? Есть ли у него потенциальная дыра в безопасности, которую включает новая система (бонусные баллы, если эта дыра может привести к судебному иску)? Не махайте рукой, «возможно» или «вероятно» так: смысл в том, что он работал хорошо в течение 20 лет, поэтому бремя доказывания лежит на стороннике перемен.

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

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

JVR
источник