Разработка лучшей стратегии развертывания ASP.NET

Question

На работе мы в настоящее время используем следующую стратегию развертывания:

• Запускаем пакетный скрипт для очистки всех временных файлов ASP.NET
• Запускаем пакетный скрипт, который компилирует каждый файл ASPX в свою собственную DLL (ASP.NET Web Сайт , а не веб-приложение)
• Скопируйте каждый индивидуально измененный файл (ASPX и DLL) в соответствующую папку в рабочей папке.сервер.
• Откройте папку Deployment Scripts, запустите каждый сценарий SQL (изменения таблиц, хранимые процедуры и т. д.) вручную в рабочей базе данных.
• Помолитесь перед сном (шучу над этим, может быть)
• На следующее утро первым делом протестируй и надейся на лучшее - исправляй ошибки по мере их появления.

Мы были укушены несколько раз вв прошлом, потому что кто-то забудет запустить скрипт, или подумает, что он что-то запустил, но не выполнил, или переписал sproc, связанный с каким-либо модулем, потому что есть два файла (один в папке Sprocs и один в папке [ModuleName] Related) илископированныйнеправильная DLL (поскольку они могут иметь одинаковые имена, например случайные буквенно-цифровые числа, сгенерированные .NET).

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

Имеется got , что является более простым способом, чем два часа для копирования и вставки отдельных ASPXстраниц, библиотек DLL, изображений, таблиц стилей и т. п. и запускайте более 30 сценариев SQL вручную.Мы используем SVN в качестве нашей системы управления исходным кодом (в основном только для обновления / фиксации, но мы не делаем ветвления), но у нас нет модульных тестов или стратегии тестирования.Могу ли я найти какой-нибудь инструмент, который поможет нам сделать наши развертывания более плавными?

Answer 1

Я не прошел через все это, но Вы неправильно его развернули * Серия 1002 * от Troy Hunt могла бы быть хорошим местом для просмотра.

Точки, обсуждаемые в серии:

• Преобразование конфигурации
• Автоматизация сборки
• Непрерывная интеграция

Answer 2

Я разработчик для BuildMaster , инструмента, который может очень легко автоматизировать шаги, которые вы описали выше, и у нас есть ограниченная бесплатная версия для команды из 5 разработчиков.

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

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

Чтобы узнать, как настроить простой план развертывания веб-приложений, вы можете запустить одно из примеров приложений, включенных в комплект. Вы также можете проверить: http://inedo.com/support/tutorials/lunchmaster/part-1, чтобы увидеть, как создать его самостоятельно - он немного устарел, поскольку мы сделали его еще проще для начала работы, но основной понятия одинаковы.

Answer 3

У нас есть четыре этапа, прежде чем его можно будет развернуть.

• Разработка
• QA
• УАТ
• Производство

У нас есть скрипты сборки (внутри бамбукового сервера сборки), работающие против QA и UAT. Наш администратор БД - единственный, кто может запускать сценарии создания для QA, UAT и PROD. Все, что идет из QA -> UAT, похоже на развертывание тестового запуска. UAT восстанавливается путем повторного копирования производственных систем.

Когда мы выпускаем в производство, мы просто создаем совершенно новый сайт и указываем его на базу данных UAT и проверяем, что он работает нормально. Затем, когда это работает хорошо, мы щелкаем по «переключателю» и направляем производственную запись IIS на следующий сайт, и меняем соединение с БД, чтобы указать на Prod DB.

Поскольку мы используем полностью разнородную структуру папок, все наши файлы копируются, поэтому нет шансов пропустить их. Поскольку у нас были тестовые прогоны развертывания в UAT, мы знаем, что не пропустили сценарий БД (сценарии БД обычно объединяются в один). Поскольку мы протестировали теневую копию веб-сайта IIS, мы знаем, что она должна работать с экологической точки зрения. Затем мы можем сделать все это в течение дня, а затем сделать последний щелчок в полночь или в любое время, уменьшив влияние на разработчиков.

tl; dr; Автоматизированная сборка и развертывание; Система UAT для развертывания в тестовом режиме; Развертывание в рабочее время; Флик-переключатель / запуск обновления БД в полночь.

Answer 4

Пожалуйста, смотрите этот пост в блоге и связанный с ним доклад Скотт Хансельман под названием "Веб-развертывание сделано потрясающе"

• Блог
• Видео

Что касается развертывания SQL, вы можете рассмотреть один из следующих вариантов:

• RikMigrations
• Migrator.NET
• FluentMigrator
• Mantee Введение & Источник

Answer 5

Предостережения - я нахожусь в среде, где мы не можем использовать MSI, пакет и т. Д. Для окончательного развертывания

Что помогло:

Сервер сборки, который выполняет полную компиляциюна сервере сборки и запускает все модульные тесты и интеграционные тесты.Зачем выяснять, что на странице aspx есть что-то, что не компилируется ночью развертывания?(Я признаю, что ваш вопрос не проясняет, происходит ли компиляция в ночь развертывания)

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

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

Вот статья о том, как лучше выполнять интеграционные тесты:http://suburbandestiny.com/Tech/?p=601 Существует масса хорошей литературы о том, как выполнять модульные тесты, но часто, если ваше приложение уже существует, вам придется проводить рефакторинг, пока не станет возможным модульное тестирование.Если это не вариант, тогда не будьте пуристом и соберите несколько интеграционных тестов, которые бывают максимально быстрыми и повторяемыми.

Храните ваши зависимости в bin вместо GAC, так как легче сказатьадминистратора, чтобы скопировать файлы, чем научить их администрировать GAC.

Answer 6

Наличие среды UAC, полностью изолированной от среды разработки и доступной только для менеджера UAT.

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

После того, как пользователи приложений и тестеры выйдутВ выпуске UAT менеджер UAT может быть авторизован для развертывания в среде PRODUCTION с использованием той же процедуры и контрольных списков, что и в выпуске UAT.Это гарантирует, что вы никогда не пропустите ни одного шага развертывания, и протестируете процесс развертывания до его запуска в производство.