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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, вы должны повернуть стол. Сделайте более рискованным, чтобы не переключаться на 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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