Я прошу прощения за длину этого поста, но мне нужно было включить много информации для правильных ответов. Я надеюсь, что это не препятствует ответам ...
Наш магазин исторически кодировал веб-сайты, используя классический ASP, а некоторые новые сайты ASP.NET были настроены как веб-сайты. Как всем известно, это означает, что исходные файлы (* .asp, * .aspx, и * .aspx.vb (или * .aspx.cs)) развертываются на серверах разработки и производства как есть.
Процесс управления конфигурацией был (и остается) полностью ручным и включает следующие этапы (требования):
- Взятие копий измененных файлов и сохранение их в папке "release" для архивирования.
- Взятие копий рабочих файлов, которые будут заменены, и сохранение их в «архивной» папке для упрощения отката.
- Создание отчета о различиях исходных файлов до и после для проверки кода или общего справочного материала при диагностике проблемы после выпуска.
- Разработчик, который кодировал изменения, не является человеком, который выполняет производственную версию. Первоначальный разработчик должен передать исходные файлы другому разработчику для дополнительного тестирования и развертывания.
Чтобы усложнить ситуацию (не с учетом вышеизложенного, но с тем, о чем я говорю ниже), мы не придерживаемся официального графика выпуска. Когда отдельные ошибки или улучшения завершены, они выпускаются. Это означает, что мы могли бы легко делать несколько релизов для сайта в неделю. Возможно даже, что данный сайт получает два разных выпуска на отдельных страниц в один и тот же день!
С тех пор как я пришел на борт, я пытался перевести команду на новые технологии, такие как веб-приложения ASP.NET и ASP.NET MVC. (Мы также взяли на себя ответственность за автономные приложения и консольные утилиты, используемые для не-веб-процессов ... поэтому моя дилемма по-прежнему применима.)
Разница между этими технологиями и устаревшими технологиями заключается в предварительной компиляции. Вместо развертывания файлов с выделенным кодом (* .aspx.vb (или * .aspx.cs)) развертывается dll или exe. Этот тип пакета развертывания вызвал несколько вопросов (проблем ??).
- Создание отчетов о различиях после компиляции источника. Пока вновь измененные исходные файлы находятся в системе разработчиков, рабочая копия является скомпилированной.
- Убедиться, что изменения, связанные с другими ошибками или улучшениями, не включены в конкретный выпуск. Это относится как к первоначальному разработчику, так и к лицу, выполняющему релиз.
- Разрешение первоначальному разработчику передать измененные файлы другому разработчику для сборки, тестирования и развертывания.
До сих пор я был единственным разработчиком в команде, работающей над этими типами сайтов и приложений, поэтому упомянутые выше конфликты и проблемы, где их вообще не было. (Я пропускаю шаг отчета о различиях, и я делаю мои собственные развертывания.) Однако я пытаюсь подтолкнуть остальную часть команды принять это плюс, чтобы лучше распределять ошибки и улучшать задачи.
В настоящее время мы используем VSS, но я настаиваю (и, скорее всего, добьюсь успеха), чтобы перевести нас в TFS. Вот некоторые идеи, которые у меня есть
Настройка отдельной системы сборки для использования разработчиком при развертывании. Это решит две проблемы: (1) различные версии / исправления Visual Studio и других библиотек между разработчиками и (2) случаи, когда лицо, выполняющее выпуск, проверило файлы локально для другого изменения. (Конечно, это не гарантирует различий между системой сборки и исходным разработчиком, но, по крайней мере, это означает, что выпуск сделан из согласованной конфигурации.
Использование меток для пометки только измененных файлов. Моя проблема в том, что, хотя я могу определить (и свернуть для сборки) измененные файлы, как мне определить файлы, которые должны быть включены в сборку, но которые были изменены , а не . Опять же, идея заключается в том, чтобы не включать отмеченные файлы, связанные с не выпущенными изменениями.
Использование меток для маркировки всех файлов для выпуска (измененные файлы и неизмененные файлы). Моя проблема с этим похожа на последнюю ... как мне убедиться, что файл, зарегистрированный другим разработчиком (скажем, они уехали в отпуск) для несвязанного изменения, не помечен и включен в эту сборку.
Используя метки, я, вероятно, мог бы написать скрипт для генерации отчетов о различиях для помеченной версии и ранее помеченной версии. Если процесс работает должным образом, то должен привести к точно , какие изменения включены в конкретный выпуск ..?
Какие-нибудь другие идеи, проблемы, достопримечательности? Хотя у меня есть некоторая гибкость процесса, некоторые требования (например, отчет о различиях или какой-либо способ легко просмотреть различия и наличие отдельного разработчика / развертывателя), скорее всего, неприкасаемы.
Большое спасибо за любую помощь, которую вы можете оказать в этом.