Что-то не так с тем, как мы делаем контроль версий?

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

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

Это кажется довольно запутанным - есть ли лучший способ справиться с этим типом сценария? Мы используем Team Foundation Server и Visual Studio 2010.

V2.0 должен был иметь то, что мы использовали как «устойчивую ветвь» (мы использовали Perforce, а не TFS), созданное для него после его выпуска. Любые исправления для v2 должны были быть внесены в эту ветку, а затем распространены обратно в ветку разработки v3, в то время как функции v3 также работали, то есть дефект на v2 мог привести к дефекту также на v3.

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

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

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

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

... путь, описанный выше, вероятно, единственный, который совершенно, совершенно неверен!

Для меня это граничит с преступностью: для TFS существует превосходное, простое для понимания руководство по ветвлению Microsoft Team Foundation Server - огромный и подробный документ с рекомендациями по стратегиям ветвления, тщательно подобранными и объясненными для всех видов различных проектов ( версия HTML). здесь )

1. У ваших разработчиков есть фундаментальное недопонимание того, как использовать контроль версий.
2. Не вступайте в дискуссию о «правильном» программном обеспечении для контроля версий. Это не проблема.
3. Каждый твик кода усложняет решение проблемы.
4. КОГДА вы решите поступить правильно, вы не сможете продолжить изменения кода, пока исправляете вещи. Вы ДОЛЖНЫ остановить все разработки и ввести код в систему контроля версий.
5. Девы должны чувствовать боль достаточно, чтобы хотя бы сесть и поговорить об этом.
6. Все программное обеспечение для контроля версий поддерживает основные понятия:
   • ВСЕ код поступает в репозиторий контроля версий.
   • Все файлы кода имеют номера версий. Эти числа автоматически увеличиваются при повторной регистрации кода.
   • TAG помечает все файлы кода (и в) конкретной версии. Таким образом, мы можем, например, пометить версию программного обеспечения версии 1.
   • ФИЛИАЛ "отворачиваться" от основного ствола .
     • Любые изменения, внесенные в ветку, не влияют на ствол.
     • Вы можете при желании объединить изменения ветви обратно в основной ствол в некоторый момент.
     • Таким образом, мы можем экспериментировать, не боясь испортить «хорошие вещи».
7. Вы должны получить контроль над версией "прыжок веры", как я это называю. ДОВЕРЯЙТЕ, что следование основным правилам поможет вам разобраться Неопытность заставляет нас думать иначе, поверь мне.
8. Вот достойный учебник. Это общее и достаточно полное, что вам не нужно рыскать множество других источников
   • Контроль версий, лучше объяснил

редактировать

• Поставьте контроль версий на свой рабочий компьютер.
  • Вы можете сделать это прямо сейчас без координации команды
  • Даже с командным контролем версий, я очень рекомендую это
  • Если ваша команда использует Git или Mercurial, вы используете независимый локальный репозиторий. Вот как работает распределенный контроль версий.
  • Вы можете использовать другое программное обеспечение VC из вашей команды. Наша команда использует Subversion, я использую Mercurial локально. Программные метафайлы VC (".svn", ".mg", скрытые папки) не конфликтуют.

Вы не действуете в качестве фактического командного хранилища. Он предназначен для управления собственной работой, рефакторинга и т. Д., А также для CYAing, когда команда продолжает использовать FUBAR для кодовой базы.

конец редактирования

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

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

Быстрый ответ: у команды разработчиков должна быть отдельная ветка Production, чтобы отделенная база кода V2.0 была отделена от главной магистрали.

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

Ваш проект также должен иметь несколько сред, for health developmentтаких как Prod, Staging, QA и Dev (иногда UAT). Эти среды должны быть настроены до перехода к производственному выпуску.

В общем, готовность к ошибкам и модификациям - это способ поддержки выпущенного приложения.

Так как TFS упоминался в качестве контроля версий, я также составил список статей, которые будут полезны для настройки среды (й) развития здравоохранения:

• Внедрение Team Foundation Server с небольшой командой разработчиков
• Добро пожаловать на интеграционную платформу TFS!
• Командная разработка с TFS Guide
• Настройка среды разработки

Нет, потому что, пока вы используете VCS, вы не делаете контроль версий.

Основной концепцией контроля версий является отслеживание разницы во времени, вы ПЛАНИРУЕТЕСЬ регистрировать некоторые различия, но на данный момент большинство ваших изменений не записано.

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

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

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

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

Я пишу как

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

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

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+FКоманда и тип //Start Iteration 2, Fix No-1, Branch No-"ABC" для поиска во всем решении очень помогают найти точные местоположения, файлы, в которых изменен код, и взять свежий код, только та часть которого может быть использована для фиксации.