Как правильно управлять фиксацией, предотвращать конфликты функций и управлять зависимостями с помощью VCS?

9

Это стало раздражающим фактором работы с большими командами: как вы управляете проверками, предотвращаете конфликты функций и правильно управляете зависимостями с помощью контроля версий?

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

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

version-control

— NickZ
источник

2

Возможный дубликат programmers.stackexchange.com/questions/5540/… , programmers.stackexchange.com/questions/15730/…

— Адам Лир

3

Лучшее решение, которое я нашел для работы с TFS, - это иметь свой собственный GIT, где я мог бы перетасовывать все необходимые мне ветвления и выполнять коммиты на TFS для незначительных этапов (небольшая функция, частичная функция), чем меньше, тем лучше, но вы должны также убедитесь, что код является правильным, когда вы фиксируете. В одной ветке для каждой функции / исправления / итерации я бы добавил TFS в конце "ветви". Однако внутренне я довольно часто имею несколько веток для разных испытаний и исследований. Инструменты TFS Power здесь очень полезны для автоматизации обратного слияния

— Newtopian 12.10.11

1

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

— Манфред

стратегия ветвления управления исходным кодом - большая тема. programmers.stackexchange.com/questions/107884/…

— комнат

@ Джон - Я думаю, что «нарушать» было опечаткой для «изменчивых»

— ChrisF

7

TFS? Беги за холмы! Двигайся как можно быстрее. Он делает много разных вещей, но ни одна из них не так хороша, как доступные лучшие инструменты породы.

Но серьезно:

Если у вас есть приличная система контроля версий (SVN, GIT и т. Д.), Я бы порекомендовал установить правила для управления филиалами, например, когда создавать филиалы, для чего, когда объединять, кого и многое другое.

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

Мы перешли на концепцию «нет мусора в багажнике», чтобы уменьшить риск графика. Эта концепция в основном содержит правило, по которому вы будете создавать ветви для работы разработки отдельно от ствола. Например, у вас может быть отдельная ветка для функции, для небольшой команды разработчиков или аналогичной. Мы используем «эпосы», чтобы описать небольшую функцию или выпускаемую часть функции и создать ветку для каждой эпопеи. По крайней мере, один раз в день все изменения из ствола сливаются в эпическую ветвь. Ключ - хорошая поддержка слияния с помощью контроля версий или отдельного инструмента (например, трехстороннее слияние). QA для эпоса будет сделан на эпической ветке. После прохождения эпическая ветвь будет объединена в транк и будет проведен интеграционный тест. У нас еще есть ветки для релизов.

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

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

Например, если у вас есть команда, в которой много людей работают удаленно и не всегда подключены к серверу управления версиями, вам следует использовать систему управления версиями, которая поддерживает распределенную модель. GIT и некоторые другие попадают в эту категорию. Насколько мне известно, TFS требует подключения к серверу, чтобы сделать файлы доступными для записи (исправлено в версии 2010?).

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

— Manfred
источник

2

"TFS? Беги за холмы!" - У меня возникает соблазн создать второй аккаунт, чтобы я дважды проголосовал за это.

— Муравей

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

— Лайонел

1

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

— Манфред

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

— Лайонел

4

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

То, насколько хорошо это работает в вашей ситуации, зависит от того, насколько хорошо VCS обрабатывает ветви и, что более важно, слияния. DVCS, такие как Git & Mercurial, делают это относительно тривиальным упражнением. СВН меньше так. Мне удалось избежать TFS, хотя я много об этом читал, боюсь, в основном, это было совершенно бесплатно. Если вы застряли с TFS, сделайте небольшой пилотный выпуск, основанный на одной функции на ветку, и посмотрите, насколько хорошо для вас слияние.

— mcottle
источник

2

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

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

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

— Лионель
источник

2

Я совершенно не согласен с работой над багажником. Если ствол сломается, все пострадают. Я также не согласен с ветвлением после основного выпуска. Что, если ошибка затрагивает два или более выпусков, вы исправляете ее в каждой ветви?

— Trasplazio Garzuglio

@ marco-dinacci: То, что вы говорите, может быть правильным, если в любой момент поддерживается более одного релиза. Однако вы игнорируете тот факт, что исправления для этих ошибок будут объединены обратно в ствол. Другие выпуски могут затем вытащить изменения. По поводу поломки багажника. Перед тем как добавить код в магистраль, вы должны убедиться, что у вас есть все последние версии исходного кода и что ваши изменения не сломали магистраль. Если он сломан, вы не должны фиксировать, пока он не исправлен. Конечно, есть свои плюсы и минусы в разных подходах.

— Лайонел

1

Я никогда не использовал TFS 2008/2010, но из того, что я читал на различных форумах, есть много негативных моментов в использовании TFS для контроля версий. Это заставило меня держаться подальше от TFS до сих пор.

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

Я посмотрел на PlasticSCM и постараюсь сделать это в ближайшем будущем.

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

— Filip
источник

1

Я думаю, что git делает все остальные программы контроля версий устаревшими. Разветвление и слияние легко, и если есть проблемы, они сдерживаются, но многие проблемы избегаются благодаря тому, что он поощряет очень частые коммиты, ветвления и слияния. Каждый пользователь получает полную копию репо (это может быть сокращено, но я работаю с довольно большой базой кода, и это не проблема), так что есть что-то вроде автоматического резервного копирования. Коммиты / push / pull бывают быстрыми, и одна из самых важных вещей - это разрыв связи между именем файла и отслеживанием. Данные файла, включая имя и путь, представляют собой большой двоичный объект данных, на который ссылается узел дерева, который не зависит от путей. Это не только безопаснее, но некоторые проблемы типа «никогда не делай этого» в чем-то вроде SVN не являются проблемой. Его можно использовать как традиционную конфигурацию концентратора или однорангового узла, и эти виды использования можно свободно смешивать в одной и той же настройке. Он криптографически защищен от недокументированных вставок. И это очень быстро.

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

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

— kylben
источник

1

Git действительно хорош, но (как и все) это не лучшее решение для всех и всего. programmers.stackexchange.com/questions/111633/…

— Ладья

4

Как Git делает Mercurial устаревшим? Особенно в среде разработки Windows. Было бы лучше сказать, что DVCS делает другие VCS устаревшими, а не бросает бензиновую бомбу и начинает священную войну.

— Маккоттл

@mcottle - я бы не пошел так далеко. SVN, например, является прекрасным примером качественного нераспределенного VCS. Можно сказать, что SVN делает CVS устаревшим, но я бы на этом остановился. Git никоим образом не делает SVN устаревшим - это совершенно другой подход, который хорош для некоторых, но плох для некоторых других (подробнее см. Ссылку выше). Например, и Git, и Hg относительно «сосут» двоичные файлы.

— Ладья

@ldigas: Каким образом git и hg "сосут" хуже с бинарными файлами, чем svn? Ни один из них не может отслеживать изменения в двоичных файлах за гранулярностью для каждого файла со всеми вытекающими последствиями. Кроме того, они оба делают svn в основном устаревшим, видя, как любой из них может делать именно то, что делает svn (кроме нескольких неясных функций), а затем некоторые; Вы просто должны настроить это таким образом. Лучшая причина для использования SVN, о которой я могу подумать, это то, что вы уже используете его, и миграция будет слишком болезненной / рискованной / дорогой.

— tdammers

@tdammers - я не заинтересован в троллинговой дискуссии. По любым пунктам выше, Google немного, и вы наткнетесь на что-то довольно быстро.

— Ладья

1

Некоторые из хороших практик, которым мы действительно следуем и которые нам очень помогли:

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

2) Периодически маркируйте свои файлы после любых незначительных значительных этапов.

3) Дайте хорошую проверку или комментарии. Это поможет при просмотре, иногда вам не нужно открывать и сравнивать между версиями.

— Баксы
источник

1

Как вы управляете проверками, предотвращаете конфликты функций и правильно управляете зависимостями с помощью контроля версий?

Это, с моей точки зрения, является двухфакторной задачей: вы должны делать это с технической (хорошая и простая и пуленепробиваемая ветвь | слияние | аудит и т. Д.) И управленческой (хорошо установленная политика «что», «когда» и «как») сторон. Два или даже три уровня кода разделения в ALM: что-то вроде «стабильный» (прошедший модульное тестирование), «нестабильный» (каждая включенная функция завершена, но приложение как продукт имеет вопросы после интеграции / да, это может произойти /) и « работа в процессе". Таким образом, правильный Менеджер проектов может уменьшить помехи в работе отдельного разработчика.

TFS (которую я не использовал, не использую и не буду использовать) имеет некоторые, AFAIK, фундаментальные проблемы в аспекте управления исходным кодом. Я просто ссылаюсь здесь на некоторые из текстов Джеймса Маккея:

— Ленивый Барсук
источник

1

Очень хорошая и свежая статья, которая прямо и кратко сравнивает и противопоставляет несколько разных способов работы с контролем версий, здесь: Source Control Done Right .

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

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

— Angelo
источник