Извините за этот длинный пост, но я думаю, что оно того стоит.
Я только начал с небольшого магазина .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 также имеет необоснованное объединение!). Возможно, это второй вопрос!