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

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

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

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

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

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

Цитата

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

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

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

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

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

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

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

Вы перечислили некоторые преимущества, а есть другие. Но что более важно, я не могу вспомнить ни одного недостатка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ищите другую работу.

Серьезно.

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

Также имейте в виду, что 30 не за горами. Это возраст, в котором большинство людей
перестань мучить дураков с радостью.

Просто предупреждаю.

РЕДАКТИРОВАТЬ

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

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

Я согласен с ответом, относящимся к статье Joel Guerrilla.

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

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

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

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

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

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

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

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

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