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

62

ОБНОВЛЕНИЕ
Я работаю в небольшой команде разработчиков, 4 парня. Все они использовали систему контроля версий. Большинство из них не могут выдержать контроль над исходным кодом и предпочитают не использовать его. Я твердо верю, что контроль источников является необходимой частью профессионального развития. Из-за нескольких проблем очень трудно убедить их использовать систему контроля версий:

  • Команда не привыкла использовать TFS . У меня было 2 тренировки, но было отведено только 1 час, что недостаточно.
  • Члены команды напрямую изменяют код на сервере. Это держит код не синхронизированным. Требование сравнения только для того, чтобы убедиться, что вы работаете с последним кодом. И возникают сложные проблемы слияния
  • Оценки времени, предлагаемые разработчиками, исключают время, необходимое для устранения любой из этих проблем. Поэтому, если я скажу «ноно», это займет в 10 раз больше ... Я должен постоянно объяснять эти проблемы и рисковать собой, потому что теперь руководство может воспринимать меня как «медленного».
  • Физические файлы на сервере отличаются неизвестным образом более чем на 100 файлов. Слияние требует знания проекта и, следовательно, сотрудничества с разработчиками, которое я не могу получить.
  • Другие проекты не синхронизированы. Разработчики продолжают испытывать недоверие к управлению источниками и поэтому усугубляют проблему, не используя систему контроля версий.
  • Разработчики утверждают, что использование управления исходными кодами расточительно, потому что объединение подвержено ошибкам и затруднено. С этим трудно спорить, потому что, когда контроль источника настолько плохо используется, а контроль источника постоянно игнорируется, он действительно подвержен ошибкам. Поэтому доказательства "говорят сами за себя" по их мнению.
  • Разработчики утверждают, что прямое изменение серверного кода в обход TFS экономит время. С этим также сложно поспорить. Поскольку слияние необходимо синхронизировать код , чтобы начать с отнимает много времени. Умножьте это на 10+ проектов, которыми мы управляем.
  • Постоянные файлы часто хранятся в том же каталоге, что и веб-проект. Таким образом, публикация (полная публикация) стирает эти файлы, которые не находятся под контролем исходного кода. Это также вызывает недоверие к управлению источниками. Потому что «публикация разрушает проект». Исправление этого (перемещение сохраненных файлов из подпапок решения) занимает много времени и отладки, поскольку эти местоположения не заданы в web.config и часто существуют в нескольких кодовых точках.

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

Что можно сделать в этой ситуации?

P.Brian.Mackey
источник
24
Ключевая часть недостающей информации: Какова ваша роль в команде?
дебилы
116
Действительно ли жизнь достаточно длинна, чтобы тратить годы на то, чтобы работать где-то так? У вас есть команда сотрудников, которые не хотят работать компетентно и профессионально, и менеджмент, которому все равно. Ты можешь лучше.
Carson63000
8
О том, что вы не привыкли к контролю над источниками: если это реальный проект, пришло время привыкнуть к контролю над источниками.
Compman
14
Либо измените свое рабочее место, либо измените свое рабочее место. Что бы вы ни решили, не стесняйтесь.
Горан Йович
11
Идея разработчика, ранее использовавшего управление исходным кодом и не любящего его, почти вне моего понимания. Возможно, они использовали это неправильно?
Джокинг

Ответы:

92

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

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

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

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

Слияние потребовало бы не только большого знания проекта

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

На вашем месте я бы пересмотрел свои карьерные перспективы ...

mattnz
источник
13
-1, «Ни один профессиональный разработчик сегодня или за последние 20 лет не сопротивлялся контролю над источниками». - полная ерунда и совершенно догматическая. Я подозреваю, что вы определяете «профессионал» как «тот, кто развивается как вы».
GrandmasterB
68
@Grandmaster: Вы говорите, что для программиста допустимо не использовать контроль исходного кода, или вы возражаете против того, что я слишком догматичен? Из всех вещей, которые я могу придумать, которые не могут быть обсуждены в 2011 году, контроль над исходными текстами будет во главе моего списка. Похоже, что 27 других согласны со мной. DVD, записанный с каждым выпуском, или копия дерева исходных текстов в папку с датой, возможно, является источником контроля.
Mattnz
8
Я говорю, что утверждение, что все профессионалы используют систему контроля версий, ложно . Я знаю много, что нет, кое-кто «сопротивлялся» этому. Контроль версий - это инструмент, похожий на IDE. Профессионалы используют инструменты, которые, по их мнению, лучше всего подходят для работы. Если они хотят использовать контроль источников, хорошо для них. Если они этого не делают, это их прерогатива. Вы утверждаете, что его «не открыто для переговоров» не имеет значения - я не знал, что вы были назначены единственным и последним арбитром в отношении того, как люди должны писать программное обеспечение. Лично я не настолько самоуверен, чтобы предположить, что я знаю лучше для всех остальных.
GrandmasterB
39
@GrandmasterB - Можно поспорить против чего угодно, если предположить, что мы принимаем неподтвержденные доказательства. Конечно, 100% разработчиков не используют систему контроля версий. Конечно, есть случай или какой-то небольшой% успешных крайних случаев. Лучшей практикой является использование системы контроля версий. Можно с уверенностью предположить, что любой разработчик, который говорит, что работает в команде, которой не нужен контроль над исходным кодом, является ковбоем. Не то, чтобы ковбои не могли кодировать, потому что они могут и часто очень хорошо на самом деле. Они просто не могут работать с теми, кто тоже может.
P.Brian.Mackey
4
@MattThrower: Даже если разработчик работает самостоятельно, я все равно рекомендую местную SVN. Честно говоря, единственный «убедительный» (то есть я убежден, что человек, принимающий решение, делает это с позиции знания), который я когда-либо слышал против контроля источников, заключается в следующем: «Нам запрещено позволять существование исторического копии нашего кода, даже если текущая копия может когда-нибудь испортиться, что приведет к потере всей нашей работы ». Мне не нравится этот аргумент, но я слышал, что иногда это происходит с совершенно секретной правительственной работой.
Брайан
31

Иногда проблемы реального мира делают его нецелесообразным.

Ложь.

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

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

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

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

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

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

Что можно сделать в такой ситуации?

Начните обучать всех, как использовать контроль исходного кода.

Обновить

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

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

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

Единственный способ преодолеть эту систему вознаграждений - это

А) Определите, что долгосрочная стоимость выше, чем кажущаяся краткосрочная стоимость.

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

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

D) Обучите людей наградам, которые вы нашли для долгосрочной ценности; значение, которое явно больше, чем краткосрочный быстрый ответ.

С. Лотт
источник
Я предложил тренироваться. Не раз, много раз. У нас были тренировки, две или три, но они провалились. Мне дали всего 1 час, чтобы обучить их ВСЕМ TFS. И выполнение было плохо. Мне дали старое "следуй за морковкой", обучение идет ... но ничего не происходит. Я пытаюсь решить эту проблему, но после стольких попыток я начинаю чувствовать себя плохим парнем просто потому, что я здесь странный человек. Я сказал им, что это неправильно, но они просто не согласны. Руководство говорит: «Да, вы используете TFS», но исполнение - 0.
P.Brian.Mackey
3
«они потерпели неудачу». Ложь. Они были подорваны системой вознаграждений, которая поощряет плохое поведение. Требуется больше обучения. Только обучение должно исправить систему вознаграждений, а не просто объяснить, как указать и щелкнуть инструмент.
S.Lott
1
@ P.Brian.Mackey: «У нас были тренировки, два или три». Пожалуйста, обновите свой вопрос, чтобы содержать всю историю. Убедитесь, что ваше описание завершено в вопросе. Не вводите новые факты в комментарии к конкретному ответу.
S.Lott
1
Хорошо, одержимость обучением неправильна - это проблема управления / политики / окружающей среды, в которой обучение является аспектом, но все обучение в мире бесполезно, если они могут его игнорировать, тогда как они будут учиться (тонуть или плавать) независимо от обучения если они не могут сделать что-нибудь еще.
Мерф
6
Один из моих одноклассников из класса VLSI сделал транзистор шириной в несколько нанометров и длиной в несколько миль (да!), Который соответствует спецификациям. Он ответил мне: «Все, что я знаю, это то, что мое дерьмо работает». У меня было больше терпимости к людям еще в колледже. Теперь я бы не хотел, чтобы в моей команде был такой человек. Я считаю, что некоторые команды должны быть обучены, а некоторые должны прощаться. Жизнь слишком коротка, чтобы ненавидеть свою работу / коллег.
Работа
17

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

кашка
источник
10

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

Это PITA в те дни, когда вы не можете воспроизвести ошибку локально, но кроме этого лучше работать, регистрироваться и двигаться дальше, зная, что CI-сервер автоматически отправит ее на dev.

CaffGeek
источник
Хорошее предложение, здорово на самом деле. Но руководство дало мне красный свет на CI. Нет средств для виртуальной машины или физического сервера. Нет времени, отведенного для настройки.
P.Brian.Mackey
7
Средства для CI-сервера? Это финансирует себя. Покажите, сколько времени потребуется на развертывание видео вручную, если это необходимо. Затем объясните, что это делается несколько раз в день. Раз несколько разработчиков. И он должен окупить себя в сэкономленное время за месяц.
CaffGeek
6
Черт, тогда запусти Дженкинс на своей машине.
Мэтью Флинн
5
+1 для блокировки структуры папок. Снимите у них права доступа к серверу, и они ДОЛЖНЫ следовать по правильному маршруту (через систему контроля
версий
8

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

Вы объяснили, что с плоской структурой команды сдвинуть изменения сверху вниз, возможно, не лучший способ приблизиться к ситуации. Один из методов, который стоит попробовать, - это получить бай-ин непосредственно от одного или двух других разработчиков, чтобы позволить концепции набрать обороты. Как только у вас появится еще один разработчик, вам будет гораздо проще распространить его среди остальных членов команды. Медленно познакомьте их с концепцией, скажем, начните работать над небольшим сайд-проектом, запустите его и перейдите в Git , или даже добавьте что-нибудь, размещенное на GitHub .

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

Если это не удается, запустите.

Ким Берджесс
источник
Я также думаю, что когда разработчики удовлетворены тем, что застряли в прошлом, они обычно следуют аксиоме «если ничего не сломано, не исправляйте ее». В большинстве мест, где я работал, был один и тот же ковбойский менталитет, потому что: 1. поскольку между разработчиками и их менеджерами существует большой разрыв в компьютерной грамотности, или 2. разработчиков так мало, что в их компании нет иерархии навыков, или сотрудник-старший. означает «Я работал 10 лет, занимаясь тем же, что и в первый раз».
Крис С
2
Общая сетевая папка с теневой копией является формой контроля версий. Очень плохая форма, чтобы быть уверенной, но это тем не менее.
Джоери Себрехтс
4
Я всегда спрашиваю, какая система контроля исходного кода используется на собеседовании. Когда технический директор одной компании сказал «Что это?», Я убежал.
Захари К
6

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

Люди склонны гораздо лучше реагировать на пример, чем на зрение, поэтому я бы посоветовал «починить» его самостоятельно:

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

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

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

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

Marce
источник
лол, хорошие предложения. Большая часть этого уже была сделана. Менеджер говорит: «Да, мы должны использовать систему контроля версий». Но команда не использует систему контроля версий. Я говорю менеджеру, а мгр просто говорит: «Да, нам нужно это использовать». Никто не ругается. Нет принуждения.
P.Brian.Mackey
3
@ P.Brian.Mackey - Иногда вам просто нужно пройти все BOFH . Однажды я уехал в отпуск, и подрядчик, работавший на меня, провел целую неделю, просматривая сайты знакомств. Когда я вернулся и обнаружил это, на его компьютере возникла необъяснимая проблема с доступом по TCP / IP, которую я не смог исправить. Попросите вашего босса отобрать у него права на хакерство непосредственно на сервере и заставить его пройти через TFS для развертывания, и они скоро очистят свои действия или выйдут, в любом случае, как вы победите.
Марк Бут
Идея Хранителя Источника хороша. Вы можете заставить их прислать вам свои изменения - или, по крайней мере, сообщить, что они сделали некоторые изменения, и обновить ваш репозиторий из diff с помощью prod. Или запустите fswatchи передайте его в репо при изменении файлов.
Джо МакМахон
4

Шаг 1 - уволить некомпетентного менеджера!

Если вы не можете выполнить шаг 1, попробуйте заставить менеджера ограничить развертывание только теми скриптами, которые взяты из системы контроля версий. Если разработчики (которым не нужно иметь права на производство на prod, см. Шаг 1, если они этого хотят) хотят, чтобы их материалы были развернуты, это должно происходить из системы контроля версий. Это решило проблему не очень хорошего управления исходным кодом, когда мы впервые перешли на использование его для работы с базами данных, а также для кода C #.

HLGEM
источник
4

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

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

JeffO
источник
3

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

У вас может возникнуть соблазн раскошелиться на проект, чтобы создать чистую версию, в то время как грязная версия обрабатывается этими ежедневными исправлениями; но наиболее вероятным результатом является то, что через несколько месяцев, когда закончится «чистая» версия, никто не сможет сказать вам, какие исправления и изменения были внесены после разветвления (потому что тот же образ мышления, который позволяет людям использовать такие методы, делает маловероятным, что они хранят записи об изменениях, которые они делают). Чистая версия устарела, грязная версия все еще работает, что происходит? Чистая версия сбрасывается, Naysays доказал право.

user281377
источник
2

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

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

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

Джейкоб Шон
источник
2

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

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

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

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

JW8
источник
1

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

ТР1
источник
1

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

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

Джонатан
источник
0

Заблокируйте любой сервер, кроме их разработки. Используйте менеджер конфигурации. Делайте регулярные идентифицируемые сборки (против тегов). Пометить каждый набор изменений (т.е. 1 набор изменений на ошибку). Мы также ставим тег на каждой сборке. Иметь систему типа QA между разработчиком и производством (как минимум). Делайте сборки в систему QA, используя правильный тег сборки. Дайте им горе за то, что они «сломали сборку».

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

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

Павел
источник
-3

Цитата:

Команда не привыкла использовать TFS

TFS оказывается Microsoft Team Foundation Server.

Мой первый инстинкт говорит: «Это последний выпуск Microsoft Visual SourceSafe»

Я был бы на стороне ваших коллег и действительно пошел бы против этого.

Нильс Бажес
источник
1
Team Foundation Server - это совершенно другой зверь, чем SourceSafe. Сравнение не честно.
Пап
Суть моего аргумента очень мало связана с TFS. Фундаментальная проблема заключается в историческом отсутствии какого-либо контроля над источниками.
P.Brian.Mackey
Они знают, что это по-другому? Я не
Нильс Басьес
@ Хильс Басхес - Они знают, что отличается?
P.Brian.Mackey
Этот TFS отличается от Source Safe.
Нильс Басхес