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

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

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

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

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

Мои вопросы:

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

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

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

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

1. Это может быть не нормально , но, как говорит Треб , это, вероятно, не так уж необычно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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