Странный цикл выпуска компании: Go Distributed Source Control?

Извините за этот длинный пост, но я думаю, что оно того стоит.

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

Команда только в прошлом году перешла с Visual Source Safe на Team Foundation Server. Проблема в том, что они по-прежнему используют TFS, как если бы это был VSS, и применяют блокировки Checkout в одной ветви кода. Всякий раз, когда исправление ошибки выдается в поле (даже для одного клиента), они просто собирают все, что есть в TFS, тестируют исправленную ошибку и внедряют для клиента! (Я сам из фармацевтического и медицинского оборудования, это невероятно!). В результате полуиспеченный код dev запускается в производство даже без тестирования. Ошибки всегда появляются в сборках релизов, но часто заказчик, который только что получил сборку, не видит этих ошибок, если не использует функцию, в которой находится ошибка. Директор знает, что это проблема, так как компания начинает расширять свою деятельность. неожиданно с некоторыми крупными клиентами, приходящими на борт и более мелкими.

Меня попросили взглянуть на опции управления исходным кодом, чтобы устранить развертывание глючного или незавершенного кода, но не жертвовать несколько асинхронной природой выпусков команд. Я использовал VSS, TFS, SVN и Bazaar в своей карьере, но TFS - это то место, где я получил большую часть своего опыта.

Ранее большинство команд, с которыми я работал, использовали решение Dev-Test-Prod с двумя или тремя ветвями, где разработчики в течение месяца работали непосредственно в Dev, а затем объединяли изменения в Test, затем Prod или продвигали «когда это будет сделано», а не на фиксированный цикл. Использовались автоматические сборки с использованием либо круиз-контроля, либо Team Build. В моей предыдущей работе Bazaar использовался, сидя на вершине SVN: разработчики работали в своих собственных небольших функциональных ветках, а затем вносили свои изменения в SVN (который был привязан к TeamCity). Это было приятно, потому что было легко изолировать изменения и делиться ими с ветвями других народов.

В обеих этих моделях была центральная ветка dev и prod (а иногда и test), через которую проталкивался код (и использовались метки для пометки сборок в prod, из которых были сделаны выпуски ... и они были превращены в ветки для исправления ошибок). к релизам и слил обратно в dev). Однако это не совсем подходит для работы здесь: нет порядка, когда будут выпущены различные функции, они будут выдвинуты, когда они завершены.

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

Я думаю, что для преодоления этого мы должны использовать сильно разветвленную модель с НИКАКИМИ ветвями dev-test-prod, скорее источник должен существовать в виде серии функциональных ветвей, которые по завершении разработки блокируются, тестируются, исправляются, блокируются. , проверено и затем выпущено. Ветви других функций могут получать изменения из других веток, когда они нуждаются / хотят, поэтому в конечном итоге все изменения будут поглощены всеми остальными. Это очень хорошо подходит для чистой модели Bazaar по сравнению с тем, что я испытал на своей последней работе.

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

Что думают люди по этому поводу?

Второй последний вопрос: меня несколько смущает точное определение управления распределенным источником: некоторые люди, кажется, полагают, что это просто отсутствие центрального хранилища, такого как TFS или SVN, некоторые говорят, что речь идет об отключении (SVN отключен на 90% и TFS имеет совершенно функциональный автономный режим), а другие говорят, что речь идет о Feature ветвлении и простоте объединения ветвей без родительско-дочерних отношений (TFS также имеет необоснованное объединение!). Возможно, это второй вопрос!

Что определяет DVCS?

В распределенном ГНКРЕ означает , что каждый клон репозитория имеет всю информацию , необходимые для совершения, обновления, филиала, слияния или поиска любого изменения в этом хранилище, не прикасаясь к серверу . Единственное, что вы можете сделать в автономном режиме, svnэто на самом деле редактировать файлы - вам нужен доступ к серверу практически для всех svnкоманд, в том числе для выполнения чего-то простого, например, поиска svn log, так что на самом деле он ближе к 0%, чем к 90%!

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

Какая модель ветвления подходит?

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

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

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

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

Для получения дополнительной информации об этих опциях, смотрите мои ответы на Стратегию использования контроля версий в модульной системе , Как использовать Subversion Repository Inside Git Repository? и контроль версий / версий для приложений, используемых несколькими компаниями .

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

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

Во-первых, DVCS - это серьезная проблема для ваших проблем - используемый инструмент контроля версий не является корнем проблем, которые необходимо решить. Может случиться так, что есть некоторые аспекты решений DVCS, которые «лучше», чем TFS, но это не то, что нужно исправить в этой точке.

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

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

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

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

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

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

Второй вопрос проще и короче, поэтому постараюсь начать с него

DVCS - это система, в которой нет ни одного «авторитетного» источника кода (кроме «по согласованию», когда он используется), и P2P-обмен данными возможен без дополнительных уровней (личное, неканоническое определение)

По теме первый вопрос

Боюсь, компании нужно перестроить рабочий процесс и переосмыслить стиль, чтобы получить «каким-то образом управляемый и предсказуемый код». Я не могу сказать о TFS (кроме личного мнения и ощущения, что это слабая система в части контроля версий / безосновательное слияние - зло), но для любой VCS в вашей ситуации («Продукт» - это набор независимых «Модулей», каждый «Заказчик» получает разные «Продукты» - верно ли это предположение?) Я бы предпочел разделить разработку модулей на отдельные ветви, иметь Продукт как «Супермодуль» (также филиал?), где каждый модуль привязан к определенной ревизии модуля- ветвь, разработка модуля использует парадигму ветвления для задачи (а ветвь модуля состоит только из наборов слияний).

Таким образом, вы всегда можете знать, какая «Коллекция» (т.е. набор модулей и соответствующие им ревизии) образуют каждый «Продукт», имеют возможность выполнять CI (для законченных и объединенных ветвей задач), модульное тестирование и сборки

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

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

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

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

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

Я лично рекомендовал бы gitлучше всего. Поначалу учиться немного сложнее, потому что он растет более органично, но в итоге кажется наиболее гибким. Но любая из трех распределенных систем, git, mercurial и bazaar, будет вам полезна (и вы часто можете даже смешивать их, например, mercurial может извлекать и перемещать в / из репозитория git, и я верю, что и базар).

Второй вопрос: меня учили, что «распределенный», в общем, означает, что вы можете перемещать объекты, и они сохраняют свою идентичность. Именно это и делает распределенный контроль версий: вы клонируете репозиторий, и он содержит те же коммиты и позволяет делать с ними те же вещи. Легкость ветвления и отключенная операция являются основными функциями пользовательского уровня, которые вытекают из принципа перемещения коммитов и схемы ориентированного графа, которая позволяет это.

К сожалению, нет известного решения ошибок в коде :)

Таким образом, вы просто пытаетесь не допустить, чтобы незаконченные check-in были захвачены в основном выпуске, и единственный ответ на это - ветвление-слияние для каждого разработчика. Я делал это в предыдущей компании, использующей Clearcase, это работало довольно хорошо (даже при том, что у нас было дюжина администраторов clearcase).

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

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

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

DVCS:

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