TFS и одноразовые релизы
Я прошу прощения за длину этого поста, но мне нужно было включить много информации для правильных ответов. Я надеюсь, что это не препятствует ответам...
Наш магазин исторически кодировал веб-сайты, используя классический ASP, а некоторые новые сайты ASP.NET были настроены как веб-сайты. Как всем известно, это означает, что исходные файлы (*.asp, *.aspx и *.aspx.vb (или *.aspx.cs)) развертываются на серверах разработки и производства как есть.
Процесс управления конфигурацией был (и остается) полностью ручным и включает следующие этапы (требования):
- Взятие копий измененных файлов и сохранение их в папке "релиз" для архивирования.
- Возьмите копии производственных файлов, которые будут заменены, и сохраните их в "архивной" папке для упрощения отката.
- Создание отчета о различиях исходных файлов до и после для проверки кода или общего справочного материала при диагностике проблемы после выпуска.
- Разработчик, который кодировал изменения, не является человеком, который выполняет производственную версию. Первоначальный разработчик должен передать исходные файлы другому разработчику для дополнительного тестирования и развертывания в производственной среде.
Чтобы усложнить ситуацию (не с учетом вышеизложенного, но с тем, о чем я говорю ниже), мы не придерживаемся официального графика выпуска. По мере исправления отдельных ошибок или улучшений они выпускаются. Это означает, что мы могли бы легко делать несколько релизов для сайта в неделю. Возможно даже, что данный сайт получает два разных релиза на отдельных страницах в один и тот же день!
С тех пор как я начал работать, я пытался перевести команду на новые технологии, такие как веб-приложения ASP.NET и ASP.NET MVC. (Мы также взяли на себя ответственность за автономные приложения и консольные утилиты, используемые для не-веб-процессов... поэтому моя дилемма по-прежнему применима.)
Разница между этими технологиями и устаревшими технологиями заключается в предварительной компиляции. Вместо развертывания файлов с выделенным кодом (*.aspx.vb (или *.aspx.cs)) развертывается dll или exe. Этот тип пакета развертывания поднял несколько вопросов (проблем??).
- Создание отчетов о различиях, когда источник был скомпилирован. Пока недавно измененные исходные файлы находятся в системе разработчиков, рабочая копия является скомпилированной.
- Убедиться, что изменения, связанные с другими ошибками или улучшениями, не включены в конкретный выпуск. Это относится как к первоначальному разработчику, так и к лицу, выполняющему релиз.
- Позволяет первоначальному разработчику передать измененные файлы другому разработчику для сборки, тестирования и развертывания.
До сих пор я был единственным разработчиком в команде, работающей над этими типами сайтов и приложений, поэтому упомянутые выше конфликты и проблемы, когда их не было. (Я пропускаю шаг отчета о различиях, и я делаю свои собственные развертывания.) Однако я пытаюсь подтолкнуть остальную часть команды принять это плюс, чтобы улучшить распределение ошибок и задач по улучшению.
В настоящее время мы используем VSS, но я настаиваю (и, скорее всего, добьюсь успеха), чтобы перевести нас на TFS. Некоторые идеи у меня есть
Настройка отдельной системы сборки для использования разработчиком при развертывании. Это решит две проблемы - (1) различные версии / исправления Visual Studio и других библиотек между разработчиками и (2) случаи, когда лицо, выполняющее выпуск, проверило файлы локально для другого изменения. (Конечно, это не гарантирует различий между системой сборки и первоначальным разработчиком, но, по крайней мере, это означает, что релиз сделан из согласованной конфигурации.
Использование меток для пометки только измененных файлов. Моя проблема в том, что, хотя я могу идентифицировать (и вытащить для сборки) измененные файлы, как мне определить файлы, которые должны быть включены в сборку, но не изменились. Опять же, идея заключается в том, чтобы не включать отмеченные файлы, связанные с не выпущенными изменениями.
Использование меток для маркировки всех файлов для выпуска (измененные файлы и неизмененные файлы). Моя проблема с этим похожа на последнюю... как мне убедиться, что файл, зарегистрированный другим разработчиком (скажем, они уехали в отпуск) для несвязанного изменения, не помечен и не включен в эту сборку.
Используя метки, я, вероятно, мог бы написать скрипт для генерации отчетов о различиях для помеченной версии и ранее помеченной версии. Если процесс работает должным образом, это должно привести именно к тому , какие изменения включены в конкретный выпуск..?
Любые другие идеи, проблемы, достопримечательности? Хотя у меня есть некоторая гибкость процесса, некоторые требования (например, отчет о различиях или какой-либо способ легко просмотреть различия и наличие отдельного разработчика / развертывателя), скорее всего, неприкосновенны.
Большое спасибо за любую помощь, которую вы можете оказать в этом.
2 ответа
Чтобы отслеживать различные версии кода и помогать вам управлять очень быстрыми циклами выпуска (ежедневно) по сравнению с долгосрочными улучшениями, вы можете использовать ветки в TFS.
Существует множество информации о ветвлении, но в целом мне нравится стараться сделать вещи простыми. Например, одна ветка называется "релиз", а другая - "разработка". Все работают над веткой разработки, но код, который будет развернут в производство, объединяется с веткой релиза непосредственно перед релизом.
Этот пост в блоге описывает процесс:
http://team-foundation-server.blogspot.com/2008/01/how-we-branch-our-code-in-tfs.html
Что ж, исходя из моего опыта работы с VS2003 и VS2010, например, является то, что структуры проекта различаются, и разрешение VS выполнять преобразование часто приводит к решению, которое либо требует большого количества рефакторинга, либо непригодно для использования. Было сказано, что; если вы можете перевести все на TFS2010, то один из способов справиться с этим - настроить разные проекты для каждого решения и использовать встроенную обработку версий TFS для разных выпусков. Вы также можете настроить сервер сборки и запланировать ночные сборки. Если сборка в порядке, вы можете внедрить эту версию в тестирование и в конечном итоге в производство. Вы должны действительно прочитать о TFS, потому что он полностью отличается от VSS и, безусловно, является огромным обновлением, позволяющим вам заниматься разработкой, ориентированной на команду.
PS TFS имеет действительно хорошую интеграцию с Sharepoint, которая поможет вам и вашей команде отслеживать все ошибки и задачи.