Это стало раздражающим фактором работы с большими командами: как вы управляете проверками, предотвращаете конфликты функций и правильно управляете зависимостями с помощью контроля версий?
В настоящее время на моем рабочем месте мы используем TFS 2008 и в начале декабря переходим на TFS 2010. Во-первых, любой источник контроля лучше, чем ничего, но какой подход кто-то нашел полезным, чтобы предотвратить многократные проверки и откат по всей истории контроля источников? Является ли энергозависимая магистраль лучшим способом для развертывания или развертывания, когда вы внедряете новую функцию и после того, как вы счастливы, слились в магистраль?
Мне бы очень хотелось услышать опыт других людей и, возможно, некоторые лучшие практики управления исходным кодом.
источник
Ответы:
TFS? Беги за холмы! Двигайся как можно быстрее. Он делает много разных вещей, но ни одна из них не так хороша, как доступные лучшие инструменты породы.
Но серьезно:
Если у вас есть приличная система контроля версий (SVN, GIT и т. Д.), Я бы порекомендовал установить правила для управления филиалами, например, когда создавать филиалы, для чего, когда объединять, кого и многое другое.
До недавнего времени мы использовали одну ветку для новой разработки («ствол»). Для релиза мы бы создали ветку от ствола. Окончательный контроль качества будет выполнен в этой ветке, и после его завершения мы выпустим (мы находимся в ежемесячных выпусках).
Мы перешли на концепцию «нет мусора в багажнике», чтобы уменьшить риск графика. Эта концепция в основном содержит правило, по которому вы будете создавать ветви для работы разработки отдельно от ствола. Например, у вас может быть отдельная ветка для функции, для небольшой команды разработчиков или аналогичной. Мы используем «эпосы», чтобы описать небольшую функцию или выпускаемую часть функции и создать ветку для каждой эпопеи. По крайней мере, один раз в день все изменения из ствола сливаются в эпическую ветвь. Ключ - хорошая поддержка слияния с помощью контроля версий или отдельного инструмента (например, трехстороннее слияние). QA для эпоса будет сделан на эпической ветке. После прохождения эпическая ветвь будет объединена в транк и будет проведен интеграционный тест. У нас еще есть ветки для релизов.
Благодаря эпическим ветвям мы существенно снизили риск графика, поскольку теперь мы можем освободить из ствола и включить все эпики, которые были успешно объединены в ствол. Эпопеи, которые не завершены, пропустят автобус и выпустят следующий релиз (в следующем месяце).
Это, конечно, может работать только в нашей среде. Скорее всего, у вас будут факторы, отличные от наших, которые будут влиять на то, что лучше всего подходит для управления филиалами.
Например, если у вас есть команда, в которой много людей работают удаленно и не всегда подключены к серверу управления версиями, вам следует использовать систему управления версиями, которая поддерживает распределенную модель. GIT и некоторые другие попадают в эту категорию. Насколько мне известно, TFS требует подключения к серверу, чтобы сделать файлы доступными для записи (исправлено в версии 2010?).
Надеюсь, мне удалось показать, что не существует «одного размера для всех». Начните с ваших процессов, в частности управления филиалом, определите требования и, наконец, выберите инструмент, который лучше всего соответствует вашим потребностям. Может быть, это TFS, а может и нет.
источник
Я рекомендую одну ветвь для каждой функции, поскольку она обеспечивает большую гибкость при принятии решения о том, какие функции отправлять, а какие откладывать.
То, насколько хорошо это работает в вашей ситуации, зависит от того, насколько хорошо VCS обрабатывает ветви и, что более важно, слияния. DVCS, такие как Git & Mercurial, делают это относительно тривиальным упражнением. СВН меньше так. Мне удалось избежать TFS, хотя я много об этом читал, боюсь, в основном, это было совершенно бесплатно. Если вы застряли с TFS, сделайте небольшой пилотный выпуск, основанный на одной функции на ветку, и посмотрите, насколько хорошо для вас слияние.
источник
Во-первых, отказ от ответственности. Трудно сказать, каков наилучший способ управления вашим источником, так как мы не знаем, как ваша команда или команды работают изо дня в день.
Вообще, лучше работать на багажнике. Разветвите его для каждого основного выпуска, чтобы исправления ошибок для версии выпуска находились в ветви, которую можно объединить обратно в ствол. Все разработчики работают над транком и регулярно фиксируют код (минимум один раз в день).
Регулярное объединение нового кода сводит к минимуму сложность объединения больших кусков кода на этапе массовой интеграции. Распространяя боль, вы почувствуете ее меньше. Чем чаще члены вашей команды фиксируют код, тем меньше им придется сливаться - потому что они всегда будут в последних источниках.
источник
Я никогда не использовал TFS 2008/2010, но из того, что я читал на различных форумах, есть много негативных моментов в использовании TFS для контроля версий. Это заставило меня держаться подальше от TFS до сих пор.
В настоящее время я использую SVN и Git, я считаю, что они оба хороши для небольших команд или для одиночной команды, но лично я бы не рекомендовал SVN для большой команды.
Я посмотрел на PlasticSCM и постараюсь сделать это в ближайшем будущем.
Я прошу прощения за то, что не ответил на ваш конкретный вопрос, выложил бы комментарий, если бы мои привилегии позволили мне.
источник
Я думаю, что git делает все остальные программы контроля версий устаревшими. Разветвление и слияние легко, и если есть проблемы, они сдерживаются, но многие проблемы избегаются благодаря тому, что он поощряет очень частые коммиты, ветвления и слияния. Каждый пользователь получает полную копию репо (это может быть сокращено, но я работаю с довольно большой базой кода, и это не проблема), так что есть что-то вроде автоматического резервного копирования. Коммиты / push / pull бывают быстрыми, и одна из самых важных вещей - это разрыв связи между именем файла и отслеживанием. Данные файла, включая имя и путь, представляют собой большой двоичный объект данных, на который ссылается узел дерева, который не зависит от путей. Это не только безопаснее, но некоторые проблемы типа «никогда не делай этого» в чем-то вроде SVN не являются проблемой. Его можно использовать как традиционную конфигурацию концентратора или однорангового узла, и эти виды использования можно свободно смешивать в одной и той же настройке. Он криптографически защищен от недокументированных вставок. И это очень быстро.
Я обнаружил, что сейчас все время использую его дома, просто для того, чтобы отслеживать документы и синхронизировать их между компьютерами, потому что его проще зафиксировать и передать на файловый сервер, чем создать резервную копию на сервере или сохранить его там.
Недостаток - это немного крутая кривая обучения, поскольку он тонкими способами нарушает все правила, к которым люди привыкли при управлении исходным кодом, но это короткая крутая кривая обучения.
источник
Некоторые из хороших практик, которым мы действительно следуем и которые нам очень помогли:
1) Убедитесь, что у вас нет доступной для записи копии файла в вашем локальном компьютере, и вы всегда проверяете возможность редактирования. (Если время от времени вам приходится работать локально, попробуйте объединить его в системе контроля версий перед EOD.)
2) Периодически маркируйте свои файлы после любых незначительных значительных этапов.
3) Дайте хорошую проверку или комментарии. Это поможет при просмотре, иногда вам не нужно открывать и сравнивать между версиями.
источник
Это, с моей точки зрения, является двухфакторной задачей: вы должны делать это с технической (хорошая и простая и пуленепробиваемая ветвь | слияние | аудит и т. Д.) И управленческой (хорошо установленная политика «что», «когда» и «как») сторон. Два или даже три уровня кода разделения в ALM: что-то вроде «стабильный» (прошедший модульное тестирование), «нестабильный» (каждая включенная функция завершена, но приложение как продукт имеет вопросы после интеграции / да, это может произойти /) и « работа в процессе". Таким образом, правильный Менеджер проектов может уменьшить помехи в работе отдельного разработчика.
TFS (которую я не использовал, не использую и не буду использовать) имеет некоторые, AFAIK, фундаментальные проблемы в аспекте управления исходным кодом. Я просто ссылаюсь здесь на некоторые из текстов Джеймса Маккея:
источник
Очень хорошая и свежая статья, которая прямо и кратко сравнивает и противопоставляет несколько разных способов работы с контролем версий, здесь: Source Control Done Right .
Я не думаю, что есть какая-то одна стратегия / лучшая практика для использования контроля версий. Зрелые команды, которые долгое время работали вместе, испытывают гораздо меньшую «боль» в этой области, даже если они не совсем соблюдают популярные «лучшие практики».
Что касается каких инструментов ... Это почти не имеет значения. Что действительно важно, так это чтобы все в вашей команде были на одной странице, насколько это возможно. Это означает, что каждый должен понимать, как управляется строка кода и что они должны делать. И вообще, на практике у вас обычно нет выбора, какой инструмент использовать. Сделать лучшее из того, что вы используете.
источник