Как я могу убедить мой отдел внедрить систему контроля версий?

Question

Я недавно присоединился к ИТ-отделу крупной страховой компании. Хотя название отдела - «IT», здесь написано много кода; Java, JSP, JavaScript, COBOL и даже немного C ++ из того, что я слышал. Все программы, которые позволяют страховщикам, брокерам и остальным работникам, одетым в галстуки, заключать новые контракты и работать с клиентами, основаны на коде, созданном этим отделом. Мне сказали, что департамент довольно хорош по стандартам материнской компании и что мы даже получили внутреннюю награду или две. В отделе 17 человек, разбитых на более мелкие группы по 2 или 3. Как вы уже догадались, начиная с части COBOL, средний возраст составляет более 40 лет (для примера, мне 29 лет) .

В настоящее время нет системы контроля версий (хотя существует общая схема резервного копирования). При необходимости файлы передаются через общие папки. Обычно в каждой группе есть один человек, ответственный за копирование «окончательной» версии файлов обратно на рабочий сервер. Я нахожу это абсурдным и даже немного опасным.

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

Я знаю основные преимущества VCS (отслеживаемость, детальное резервное копирование, учет и т.д.). Я хочу подкрепить свой случай реалистичными примерами и примерами реальной добавленной стоимости по сравнению с затратами на реализацию, а не просто «но-но-но, мы должны иметь VCS, которую вы обманываете!" : -)

Answer 1

Вам не обязательно их разрешение.

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

Тогда смотри и смотри, что происходит.

редактирует

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

Как и предполагалось, такой же подход может быть применен к другим областям:

• системы отслеживания проблем / ошибок
• качественные инструменты
• время отслеживания
• непрерывная интеграция
• вики для базы знаний, HOWTO, руководства, учебные пособия, презентации, скринкасты
• разные IDE и инструменты
• инструменты для сборки
• автоматизированное развертывание
• различные сценарии, которые сэкономили бы время вашей команды

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

Answer 2

У Джоэла Спольски есть отличная статья: Готово, когда ты только хрюкаешь

Цитата

Никто в вашей команде не хочет использовать управления источником? Создайте свой собственный CVS хранилище, на вашем собственном жестком диске, если необходимо. Даже без сотрудничества, Вы можете проверить свой код в независимо от всех остальных. Тогда, когда у них есть проблемы, которые контроль источника может решить (кто-то случайно набирает rm * ~ вместо гм * ~), они придут к вам за помощью. В конце концов, люди поймут, что у них могут быть свои собственные проверки, тоже.

Answer 3

Управление? Я выделю жирным шрифтом выражения и слова, которые вы должны использовать:

Вы должны показать несколько примеров того, как VCS предотвратит потерю компании, если произойдет какая-либо ошибка / ошибки или авария. Решить все проблемы будет быстрее, поэтому обслуживание систем не будет таким ленивым , и люди станут более продуктивными .

Вы должны также упомянуть, что реализация VCS не требует затрат .

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

Answer 4

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

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

2. Вы даете правильные аргументы руководству, которое все взволновано (замечательно!) И требует, чтобы контроль версий был установлен и использовался всеми. Вот в чем дело: если на данный момент другие разработчики еще не проданы этой идее, то (а) они могут быть враждебны идее, которую навязывает им руководство, и (б) они могут не понравиться вам за то, что вы были причиной всего этого.

Так что же является хорошим аргументом, чтобы убедить коллег-разработчиков? Как человек, который использует Subversion (кстати, тот, который я рекомендую в данном случае) даже для своих сольных проектов, вот некоторые преимущества, которые я могу себе представить:

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

2. Контроль версий позволяет очень легко увидеть , что меняется в коде каждый раз. Это может звучать тривиально, но когда вы начинаете изменять код, через некоторое время легко потерять след. Но с VC это всегда "svn diff" (или эквивалент), всегда.

3. Контроль версий позволяет очень легко увидеть , кто каждый раз изменял код. Так что, например, когда что-то ломается, вы знаете, кто виноват. (Не случайно команда subversion, которая показывает, кто в последний раз изменил каждую строку, называется "svn blame".)

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

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

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

Answer 5

Я согласен с ответом на статью Джоэла Партизана.

1. Установить / использовать какую-то вещь с низкими накладными расходами. Hg (Mercurial) легок в смешанном окружении и хорош, потому что вы можете выручить и использовать что-то еще простым способом.
2. Вы должны делиться своими вещами, не шутя об этом. Когда кому-то нужен ваш код, экспортируйте его и используйте «стандартный» корпоративный метод (общая папка или что-то еще)
3. Когда вы получаете код, всегда импортируйте его в репозитории, если вы думаете, что это новый коммит репозитория, который у вас уже есть, попробуйте вставить его в него.
4. Рано или поздно у вас будет код для нескольких проектов и, возможно, некоторые из них будут коммитены в некоторых репозиториях. Затем вы можете открыть их с помощью интерфейса веб-сервера mercurials (hg serve -p XXXX).
5. Когда приходит время, когда кто-то не знает, почему что-то вдруг не работает, как должно быть, и пытается выяснить, почему это работает в прошлый понедельник ... и вы знаете, что у вас есть этот код в репозитории выходят и спрашивают, можете ли вы оказать какую-либо помощь. Получите ошибочный код, зафиксируйте его в своих репозиториях и откройте с помощью hg serve. Посмотри на это в браузере.

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

Answer 6

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

Answer 7

С чисто деловой точки зрения, и в зависимости от размера и характера вашей материнской компании, ИТ-аудитор может посчитать ваше отсутствие VCS находкой (то есть что-то, что требует исправления). Я полагаю, что вы могли бы повысить свой уровень в управлении, сказав им, что любой CVS - это отличный способ показать, что ваш отдел уважает свои ресурсы и работает структурированным и эффективным способом, что аудиторы всегда любят видеть.

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

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

Answer 8

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

Кроме того, поскольку Subversion и некоторые другие бесплатны, отметьте, что нет реальной стоимости покупки, но есть время на внедрение.

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

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

Answer 9

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

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

Answer 10

Я бы также рекомендовал начать с реализации VCS (системы контроля версий) для самостоятельно . Я бы рекомендовал использовать один из распределенных VCS (Git, Mercurial, Bazaar) вместо централизованного Subversion, потому что было бы проще создать центральное хранилище (или хранилища) путем клонирования, чем перемещать хранилище Subversion в центральное место. , Распределенный SCM может также использоваться в небольшой группе для обмена идеями.

Несколько преимуществ (современных) систем контроля версий:

• Вы всегда можете вернуться ( вернуться назад ) к последней рабочей версии вашего кода (при условии, что вы следуете некоторым нормальным соглашениям по управлению версиями, таким как, по крайней мере, пометка только проверенного кода). При совместном использовании кода через папки может оказаться, что ни одна версия не работает, резервные копии были удалены для экономии места, а восстановление кода из резервной копии утомительно / никогда не проверялось.

• Вы можете переключаться между работой над какой-то новой функцией (некоторые экспериментальные работы) и работой над срочным исправлением в развернутой в настоящее время версии (работа по обслуживанию) благодаря ветвям (и stash / shelve для незафиксированных работа).

• Если вы будете следовать рекомендациям по управлению версиями (небольшие и часто коммиты, изменения, связанные с одной вещью, написанием хорошего коммита с описанием изменений и причинами изменений), вам будет намного, намного легче находить ошибки, будь то с помощью деления пополам истории , чтобы найти, какие изменения привели к ошибке, или с помощью системы контроля версий, чтобы выяснить, кто отвечал за данную область кода ( annotete / blame ).