При достижении лучшей стратегии развертывания ASP.NET

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

  • Разработка
  • ОК
  • UAT
  • Продукция

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

После того, как пользователи приложений и тестеры подписали выход UAT, менеджер UAT может быть разрешен для развертывания в среде ПРОДУКТ, используя ту же самую процедуру и контрольные списки, что и выпуск UAT. Это гарантирует, что вы никогда не пропустите какие-либо шаги по развертыванию и протестируйте процесс развертывания до его перемещения в производство.

Ответ 6

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

Вещи, которые помогли:

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

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

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

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

Сохраняйте свои зависимости в bin вместо GAC, так как проще сказать администратору скопировать файлы, чем обучать их администрированию GAC.