Необычно ли для небольшой компании (15 разработчиков) не использовать управляемый источник / контроль версий? [закрыто]

152

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

Компания, в которой я работаю (которая останется анонимной), использует сетевой ресурс для размещения своего исходного кода и выпущенного кода. Разработчик или менеджер несут ответственность за ручное перемещение исходного кода в нужную папку в зависимости от того, выпущен ли он, какая это версия и что с этим. У нас есть различные электронные таблицы, в которых мы записываем имена и версии файлов, а также то, что изменилось, и некоторые команды также размещают сведения о различных версиях в верхней части каждого файла. Кажется, что каждая команда (2-3 команды) делает это по-своему внутри компании. Как вы можете себе представить, это организованный беспорядок - организованный, потому что «правильные люди» знают, где их вещи, но беспорядок, потому что все по-другому, и он полагается на то, что люди помнят, что делать в любое время.

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

  • Мы в настоящее время уязвимы; в любой момент кто-то может забыть выполнить одно из многих действий по выпуску, которые мы должны сделать, что может означать, что целые версии хранятся неправильно. Может потребоваться часы или даже дни, чтобы собрать версию, если это необходимо
  • Мы разрабатываем новые функции вместе с исправлениями ошибок, и часто приходится задерживать выпуск того или другого, потому что некоторые работы еще не завершены. Мы также должны заставить клиентов брать версии, включающие новые функции, даже если они просто хотят исправить ошибку, потому что есть только одна версия, над которой мы все работаем
  • У нас возникают проблемы с Visual Studio, потому что несколько разработчиков используют одни и те же проекты одновременно (не одни и те же файлы, но это по-прежнему вызывает проблемы).
  • Есть только 15 разработчиков, но мы все делаем вещи по-разному; разве не лучше было бы использовать стандартный для всей компании подход, которому мы все должны следовать?

Мои вопросы:

  1. Это нормально для группы такого размера, чтобы не иметь контроля источника?
  2. Я до сих пор были даны лишь неопределенные причины , не имея контроля версий - какие причины могли бы предложить может быть действителен не осуществляет контроль источника, учитывая информацию выше?
  3. Есть ли еще какие-то причины для контроля версий, которые я мог бы добавить в свой арсенал?

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

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

заранее спасибо

LordScree
источник
3
Похоже, они не очень далеки от работы с DVCS, как Mercurial. Люди, которые тянут свои ноги, все еще могут «использовать» Mercurial, если существующая папка фактически была превращена в хранилище. С их точки зрения это выглядело бы почти одинаково, и вы могли бы зафиксировать изменения, если бы они этого не сделали.
Джон Фишер
19
ОБНОВЛЕНИЕ (Спустя почти год после того, как я задал этот вопрос): В течение прошлого года я проводил кампанию, уговаривал, умолял и шутил, пока не дошел до того, что, черт побери, меня несколько раз уволили за неповиновение. Я рад сообщить, что компания, о которой идет речь, теперь, наконец, серьезно рассматривает систему контроля версий, чтобы внедрить TFS после пробного периода в месяц или около того, в то время как мы гарантируем, что все разработчики довольны новыми процессами. Это был в значительной степени положительный ответ, который я получил от этого вопроса у программистов. SE вселил в меня уверенность в его решении. Приветствия.
Оливер-Клэр
10
Разработчики, не использующие контроль источников, эквивалентны хирургам, которые не моют руки или не используют грязную посуду для работы. Это профессионально некомпетентно, и для такого рода злоупотреблений нет оправдания.
Тим
1
Несмотря на то, что электричество было изобретено давным-давно и широко распространено в нашей повседневной жизни, некоторые люди все еще предпочитают работать с надписью на свечах на восковой доске с помощью заостренной палки.
Newtopian
2
15 разработчиков вряд ли маленький магазин.
Луи Коттманн

Ответы:

108
  1. Это может быть не нормально , но, как говорит Треб , это, вероятно, не так уж необычно.
  2. Как уже говорили другие, нет веских причин для того, чтобы не иметь контроля над исходным кодом в компании вашего размера. Таким образом, вам необходимо выявить и атаковать неправильные причины:

    а) основным является статус-кво : «если оно не сломано, не исправляйте его». Это сложно: вы можете начать указывать на все вещи, которые работают не так, как следовало бы (что может быстро пометить вас как «отрицательного человека»), или просто подождать, пока что-то взорвется (что может никогда не произойти) случиться), или вы могли бы подчеркнуть все вещи, которые могут пойти не так. К сожалению, люди, отвечающие за небольшие компании, относительно невосприимчивы к «вещам, которые могут пойти не так», пока они действительно не пойдут не так ...

    б) невежество / страх / неуверенность : «мы на самом деле не понимаем, что такое контроль источников; мы не знаем, как его использовать; мы не знаем, какой инструмент выбрать; это ограничит наш стиль» . Это одна из причин, по которой я бы не стал отправлять их сюда! Сам по себе это может быть довольно сложный заказ, но я думаю, чтобы максимизировать свои шансы, вам нужно представить решение «под ключ», а не слишком много вариантов или альтернатив. Вам нужно четкое представление о том, как вы хотите приспособить / преобразовать свой рабочий процесс для работы с данным инструментом; как / если вы планируете портировать существующий код; насколько быстро вы можете «обучить» пользователей и заставить их работать; как вы можете управлять переходным периодом (если он есть); сколько это может «стоить» (в часах, если не в долларах).

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

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

(Вы читали / слышали о функции изменения ?)

оборота Бенджол
источник
2
Спасибо за (к сожалению) необходимое различие между нормальным и необычным. +1
Кеппла
29
+1 за невежество / фуд. Если вы профессиональный разработчик программного обеспечения, но не используете SCM, значит, нет. период.
Крис Торнтон
2
Просто из любопытства, кто будет платить 300 долларов за человека за контроль над источниками (Valut, согласно вашей вики-ссылке), когда существует бесчисленное количество бесплатных приложений?
Роб
11
по пункту 2: я не вижу какой-либо веской причины для команды любого размера (включая команду из 1) не использовать контроль источника ...?
Джеймс Хоури
1
Другая причина в том, что некоторые небольшие группы не имеют контроля версий - в настройке участвуют некоторые накладные расходы и обучение. Вам нужен сервер для размещения базы кода. Вам необходимо администрировать сервер и программное обеспечение VC на этом сервере. Необходимо выполнить резервное копирование базы данных VC, создать и протестировать план восстановления и отслеживать резервные копии, чтобы убедиться, что резервное копирование / восстановление все еще действует. Вся эта администрация требует времени. В организациях с плохим управлением программным обеспечением время, затрачиваемое разработчиками на администрирование системы VC, может быть наказано, а не вознаграждено.
Джей Элстон
185

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

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

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

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

Джон Перди
источник
45
К сожалению, непростительное не приравнивается к необычному ...
Марьян Венема
6
Не говоря уже о том, что есть БЕСПЛАТНЫЕ провайдеры контроля версий, так что это не так, как если бы это был дорогой курс действий.
Манторок
9
Это может быть дорогостоящим, если заставить людей изменить свои привычки, рабочий процесс и процедуры.
user1936
4
@Rook: Абсолютно. Но я бы предпочел иметь сетку безопасности, которая мне не нужна, чем нужна мне, которой у меня нет. Я программировал задолго до того, как понял, что такое система контроля версий. Хотя это и не обязательно, лишать себя хорошего инструмента - глупо.
Джон Перди
12
Я не мог представить разработку без контроля исходного кода, даже когда я единственный разработчик.
webbiedave
34

Это нормально для группы такого размера, чтобы не иметь контроля источника?

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

До сих пор мне приводили только смутные причины отсутствия контроля над источниками - какие причины, по вашему мнению, могут быть действительными для отказа от контроля источников, учитывая приведенную выше информацию?

Смотрите этот вопрос на SO для хорошего обсуждения. Принятый ответ гласит:
«Нет веских причин не использовать контроль версий. Ни одного».

Есть ли еще какие-то причины для контроля версий, которые я мог бы добавить в свой арсенал?

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

Треб
источник
"значительное число не" ... хм ... с 15 разработчиками на одной кодовой базе? Там , где я, мы добавили SCC , когда мы были ... 5 + 2 дэвы на той же кодовой базе , и мы чувствовали, что высокое время для этого. Я очень надеюсь, что 15 разработчиков и без SCC в одной и той же кодовой базе очень необычно :-)
Martin Ba
3
@Martin: Это не что необычно , чтобы найти 15 человек , которые все страдают от изобретено не здесь синдром ... Я бы предположил , что , возможно , 5% всех малых (<20 сотрудников) компании не имеют никакого контроля источника. Я надеюсь, что ваш опыт отличается от моего ;-)
Треб
+1 для не необычного, к сожалению.
Джонас
6
+1 для не необычного. Некоторые люди просто не понимают, что преимущества контроля исходного кода перевешивают затраты. Они опасаются затрат и объединяются путем копирования файлов или исправлений в «центральное» рабочее пространство слияния для «сборки»; в основном потому, что они поняли, что это сработает, и никто не вкладывает средства в среду разработки. Как правило, это происходит из-за того, что у них так много работы над кодом, что они не могут тратить время на разработку среды. Я считаю, что экономия времени в более эффективной среде больше, чем окупаемость вложений разработчика, работающего над ней
Эдвин Бак,
27

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

Просто найдите инструмент, который поможет вам. Размер не имеет значения везде. Качество имеет значение везде.

Kangkan
источник
4
+1, я в настоящее время одна команда разработчиков, и я использую контроль версий. Я даже использую систему контроля версий дома, чтобы управлять личными документами, не связанными с разработкой программного обеспечения, такими как кулинарные рецепты и мое резюме.
maple_shaft
1
+1, множество небольших магазинов начинают использовать zip-файлы в качестве своего архива. Думая «Я могу вернуться к этому моменту, поэтому я просто застегну все это». Это не то же самое, совсем нет. Когда вы ознакомитесь со SCM и великолепными инструментами, которые построены на вершине (log, diff, обвинения и т. Д.), Вы никогда не вернетесь.
Крис Торнтон
5
Еще одно замечательное применение SCM: я прихожу в понедельник и задаюсь вопросом, какого черта я работал в прошлую пятницу. Я просто делаю diff или смотрю последний журнал регистрации, и я немедленно возвращаюсь в зону.
Крис Торнтон
1
Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back?Да, я просто использую последнюю резервную копию, которую я сделал вручную, несколько недель назад, и я делаю резервные копии всякий раз, когда хочу внести существенные изменения. Не подвел меня еще несколько лет, и никогда не нуждался (или чувствовал, что я должен был использовать) контроль над источниками ...
Mehrdad
Я единственный, кто занимается разработкой в ​​нашей компании (я также занимаюсь ИТ-технологиями), и когда я начинал, я не использовал систему контроля версий, никогда не было катастрофы, но в конце концов я понял, насколько мы на грани. Я установил Mercuarial чуть позже, даже не использовав его раньше, и с помощью интерфейса Windows для него это очень помогло.
Тони Петерсон
17

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

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

  • Вместо того, чтобы записывать изменения в электронную таблицу, система SCM отслеживает не только то, что изменилось, но кто изменил это и почему.

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

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

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

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

jwernerny
источник
9

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

  • Разрабатываемый вами продукт является системой контроля версий; Менеджеры обеспокоены предотвращением влияния существующих продуктов на разработку и реализацию нового продукта.

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

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

Есть ли еще какие-то причины для контроля версий, которые я мог бы добавить в свой арсенал?

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

  • Экономит место на диске. Большинство систем контроля версий сохраняют только дельты между файлами. В настоящее время вы сохраняете полную копию каждой версии каждого файла. (Резервное копирование всех этих копий должно занять много времени и места!)

  • Несколько разработчиков могут одновременно работать над одним файлом и согласовывать различия без особых проблем. Объединение изменений, конечно, возможно без VCS, но практически невозможно отследить, кто что изменил, когда и почему в этом случае.

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

  • Лучший процесс облегчает наем и удержание талантливых разработчиков.

Калеб
источник
1
Во втором пункте многие VCS сохраняют дельты, но Git сохраняет весь файл для каждого уникального хэша файла. Но это на самом деле не имеет значения; дисковое пространство дешевое, а исходный код крошечный. gitready.com/beginner/2009/02/17/how-git-stores-your-data.html
Джеймс
8

Это нормально для группы такого размера, чтобы не иметь контроля источника?

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

До сих пор мне приводили только смутные причины отсутствия контроля над источниками - какие причины, по вашему мнению, могут быть действительными для отказа от контроля источников, учитывая приведенную выше информацию?

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

Есть ли еще какие-то причины для контроля версий, которые я мог бы добавить в свой арсенал?

Да, есть много причин.

  1. Ветвление дает вам возможность разрабатывать новые функциональные возможности, не мешая другим разработкам.
  2. Каждый коммит дает вам информацию о том, что именно было изменено, кто это сделал и когда это изменение было сделано.
  3. Вы можете легко фиксировать исправления и развертывать их для клиентов, а также оставлять незавершенные новые функции.
  4. Вы можете поддерживать разные версии, если клиенты боятся переходить на более новую версию.
  5. Вы можете легко работать над одним и тем же проектом (даже с одинаковыми исходными файлами!).
  6. Вы можете легко отменить ошибку, сохранив изменения после этой совершенной ошибки.
оборота Гертен
источник
«был один человек, которому вы должны отправить измененный код, и он объединит его» - это не так уж плохо. Многие проекты с открытым исходным кодом работают таким образом. Вы отправляете патчи сопровождающему. Но это не будет масштабироваться для больших команд, очевидно.
Алекс Жасмин
6

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

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

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

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

tdammers
источник
4
да, нет причин не использовать его самостоятельно, а затем по совпадению показать его силу коллеге, когда он меньше всего этого ожидает.
gtrak
5

Моя компания использует GIT для контроля версий. Компания является одним разработчиком, одним генеральным директором, одним охранником, одной уборщицей и одним приемщиком. Все они я. Контроль версий исходного кода ОБЯЗАН каждый раз.

Жоау Пинту Херонимо
источник
5

Я работаю над многими проектами самостоятельно и все еще использую контроль версий. Размер не имеет значения. Это всегда помогает иметь контроль версий.

Есть причина, по которой он занимает первое место в тесте Джоэла: http://www.joelonsoftware.com/articles/fog0000000043.html

Кроме того, это делает возможным № 2 и № 3 в списке.

Сарел Бота
источник
4

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

Все последовали его примеру, и вскоре мы внедрили CI ( CruiseControl ) и произвели революцию в нашем процессе сборки и выпуска, включив в него автоматизацию и проверки качества.

Burhan Ali
источник
4

WTF ?! Это может быть самый смешной вопрос, который я когда-либо видел. Вам нужно найти новую работу. 15 разработчиков ?! Вы думаете, что это маленькая команда? Это безумие. Менеджер должен быть немедленно уволен. Честно говоря, у меня будут кошмары после прочтения этого вопроса. Пожалуйста, расскажите нам о продукте, который вы продаете, чтобы мы все знали, не покупать его! Я не знаю, что страшнее, этот вопрос или ответы о том, что это не необычно!

J-Dog
источник
3

Я не могу представить, как 15 разработчиков могут работать без какого-либо контроля версий. Однако из:

(...) использует сетевой ресурс для размещения своего исходного кода (...)

Я предполагаю, что вы создали свой собственный контроль версий бедного человека, такой как VSS (также основанный на общей папке). Это рискованно и не эффективно.

Объясните своему боссу, насколько это плохо, вложите деньги в 2-дневное обучение по SVN или GIT и начните использовать реальную систему контроля версий, пока ваш код все еще находится в разумной форме.

Михал Шрайер
источник
2
Я не уверен, что вам нужно два дня, чтобы выучить SVN. С 15 разработчиками, они не могут быть «свежими из школы». Наверняка половина уже использовала его где-то раньше.
Майкл Блэкберн
1
@MichaelBlackburn: я согласен. Я не прояснил себя. Я думал о двух днях для обучения и настройки (настройка репо, код импорта и т. Д.)
Михал Шрайер,
3

Если я не совершаю несколько раз в день или, по крайней мере, перед тем, как уехать домой, я чувствую, что… чего-то не хватает, что-то не так.

Однажды я работал в компании, в которой работали всего 2 разработчика (я + длинноволосый администратор), еще в 1998 году. Уже тогда мы использовали SVN. Это просто так удобно.

Несколько раз в моей карьере я терял дни работы, потому что я делал что-то вроде mv вместо cp, а затем rm -rf. Заставил меня плакать и бродить по улицам города в отчаянии.

За 13 лет работы в SE я работал в 5 компаниях, был на некоторых конференциях и никогда не сталкивался с компанией, не использующей контроль версий.

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

me1974
источник
1
svnне существовало в 1998 году.
Фахим Митха
3

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

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

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

Ладно, воспоминания до меня доходят. Подписание. Удачи.

radarbob
источник
Спасибо друг. Мне нравится определение лидера "делать правильные вещи", которое отличается от определения менеджера "делать правильные вещи". То есть менеджер делает то, что он делает правильно, но это может быть неправильно. Лидер делает правильные вещи, но часто нужен менеджер, чтобы сделать это правильно. Определенно стоит +1 :)
Оливер-Клэр
2
  1. Возьми секундомер,
    • Подсчитайте время, которое вы проводите в электронной таблице только для синхронизации версий
    • Считайте время, которое вы тратите на восстановление сломанных версий
    • посчитайте, сколько раз люди кричат ​​в коридоре: « Я редактирую main.c !, просто чтобы убедиться, что больше никого нет!» ,
    • подсчитайте количество жалоб от клиентов, потому что их исправление содержало другие изменения
    • посчитайте задержку выпуска только потому, что вы не смогли синхронизировать версии
  2. Сделайте powerpoint с этими данными, сравните с тем, как будет работать vcs.
  3. Показать управление
Кабельное телевидение
источник
2

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

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

Подумайте и о внешнем хранилище. Наводнение или пожар не так уж необычны. Что бы произошло, если бы в здании был пожар в нерабочее время. Сколько месяцев работы будет потеряно. Хранилище управляемого кода, такое как github, было бы полезно для этого. Даже использование простого сервера SVN в размещенной службе будет шагом вперед в этой области.

Билл Липер
источник
2

LordScree, я почти в таком же затруднительном положении, что и вы, моя непосредственная команда - около 15 разработчиков. Я не верю (почти в ужас), что контроль над источниками не используется. Мой первоначальный ответ на «мы должны использовать систему контроля версий» был «у нас нет времени на реализацию». Для меня, как и в нижнем белье, контроль источников не является обязательным. Через несколько месяцев у меня тоже есть разрешение на внедрение TFS, выбранное организацией, потому что это MS и поставляется с 90-дневной пробной версией. В итоге, очень трудно убедить организацию в необходимости контроля над источниками, когда они бездельничают без него. Я говорю разработчикам, что всякий раз, когда вы обнаруживаете, что вы создаете резервные копии файлов, особенно с указанием даты в резервной копии имени файла или каталога, это пример того, как вы помещаете что-то в систему контроля версий. Я не У меня нет для вас блестящих ответов, но я верю, что это необычно. Я сражаюсь в той же битве и буду держать вас в курсе прогресса. И, надеюсь, будет прогресс, если я буду искать в другом месте, потому что я не могу работать в хаосе!

ММФ
источник
Я думаю, что мой самый сильный аргумент в пользу контроля над источниками был из-за риска для бизнеса не иметь его. Неправильный выпуск продукта может стоить рабочего времени или даже дней, чтобы разобраться, не говоря уже о испорченных отношениях с клиентом. Это реальный риск без управления управляемым источником из-за количества ручных шагов, необходимых для выпуска программного обеспечения и отслеживания таких вещей, как версии для каждого клиента. Постарайтесь использовать свой подход с точки зрения бизнеса, поскольку менеджеры с большей вероятностью прислушаются к этим аргументам, чем просто «все остальные используют его, поэтому мы должны это делать».
Оливер-Клэр
Еще одним фактором, способствующим этому, было то, что аккредитация по ISO 9001, которую я проверяю на своем рабочем месте, отрицательно сказывается на ИТ-бизнесе за отсутствие контроля над источниками. Аккредитация полезна для подачи заявок на новые проекты и деловые партнерские отношения, так как ее часто ищут в тендерной документации. Желаем удачи в вашей борьбе!
Оливер-Клэр
1

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

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

Николас Смит
источник
1

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

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

Просто скажите им, как здорово найти приложение, которое было 1 января этого года

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

Вау, эта ошибка 154256 была исправлена ​​в этом коммите.

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

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

V4Vendetta
источник
1

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

торы
источник
1

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

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

Есть много причин использовать систему управления версиями. По крайней мере, перестань двигаться. Работа с патчами. Системы управления версиями могут делать именно то, что вы говорите.

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

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

Стив Бузонас
источник
1

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

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

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

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

Билл К
источник
1

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

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

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

В любом случае я / другие разработчики только начали использовать SCM лично.

средняя высота сизигийного прилива
источник
0

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

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

Главные причины, по которым я не использовал ископаемые или другие VCS:

  1. Многие из «программистов» являются сценаристами и не понимают, как ими пользоваться
  2. Те, кто мог учиться, думают, что это неудобство в использовании
  3. Эти люди - старая гвардия, которые хорошо разбираются в сетевых папках, поэтому каждый должен
  4. Ни у кого нет времени, чтобы правильно его настроить или научиться им пользоваться
  5. Хотя функции могут быть отличными, ни одна из них не нужна

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

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

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

Спенсер Рэтбун
источник
0

Теперь, когда инструменты DVCS, такие как Git и Mercurial, доступны и невероятно просты в настройке и использовании, даже команде из 1 (!) Не нужно оправдывать отказ от управления исходным кодом. Речь идет не о размерах команды, а о том, чтобы иметь закомментированную историю ваших изменений и возможность поддерживать рабочие процессы, такие как исправление производственных проблем во время работы над новым выпуском и отслеживание состояния исходного кода для разных версий.

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

Мартин
источник
Управление версиями было легко настроить с помощью Source Safe и SVN. Даже CVS. (Git НЕ легко установить и использовать в среде Windows)
Тим
0

Вы должны немедленно получить контроль версий GIT. Вы можете использовать его даже из Google Code Project Hosting. Когда другие видят, что вы вносите изменения одним нажатием, когда они копируют вещи вручную, возможно, они передумали об этом.

Мистер смит
источник
Я абсолютно согласен. Программа установки Git невероятно проста в использовании, и вы можете приступить к работе за считанные минуты. Расширенные функции могут ждать, базовый контроль версий не может ждать. cd topleveldirectory; git init; git add *; git commit -m "initial commit"
пылесос
0

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

Например, мы работали над социальной сетью класса ab, написанной на PHP, и клиент хотел, чтобы функциональность могла подписываться на профиль пользователя. По сути, функциональность была заключена в такую ​​проверку, если (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {затем выполнить код}

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

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

Дуэйн Чаррингтон
источник
0

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

Вы можете найти некоторую информацию здесь: http://www.internetcontact.be/scm/?page_id=358

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

Ив
источник