Предложения по использованию передовых методов развертывания веб-сайтов ASP.NET

Question

Я просмотрел соответствующие вопросы, и ни один из них не предоставил мне информацию, которую я ищу.

В настоящее время команда, над которой я работаю, выполняет развертывание отдельных файлов .aspx (и .aspx.vb) для исправления / улучшения ошибок. Я пытаюсь повлиять на изменения, так как действительно считаю, что развертывание «всего скомпилированного сайта» менее подвержено ошибкам. Поскольку это значительное изменение по сравнению с тем, как все было сделано, мои предложения встретили значительное сопротивление.

Поскольку мое google-fu в последнее время не было на должном уровне, я надеялся, что SO-сообщество может либо сказать мне, что я не в духе, и что нет ничего плохого в перемещении отдельных файлов, либо указать мне на некоторые действительно хорошие ресурсы, которые позволили бы мне сделать более веские аргументы.

Edit:

Все это было отличной информацией и подкрепляет аргументы, которые я уже приводил, кто-нибудь может поспорить с другой стороной?

Answer 1

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

Сборка и развертывание могут быть детализированы, поэтому, как минимум, попробуйте взглянуть на Microsoft Web Deployment Tool (http://www.iis.net/extensions/WebDeploymentTool). Установите инструмент на свой сервер сборки и установите его на свой сервер развертывания. Подготовьте ASP Содержимое .NET локально с помощью команды публикации Visual Studio, а затем с помощью вышеупомянутого инструмента синхронизируйте весь пакет на сервере развертывания. Мне нравится этот подход, поскольку он может быть полностью автоматизирован. При выполнении сборок и развертываний стремитесь к полной автоматизации, чтобы уменьшить потенциал ошибки.

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

Answer 2

Лично для меня откат немедленно является самым важным. Опять же, проекты сайтов очень сложны, когда дело доходит до отслеживания изменений.

хорошее подробное сравнение можно найти здесь . Я репродуцирую статью здесь.

1) Развертывание. Если вам нужно развернуть на месте, эта модель идеально подходит. Однако это не рекомендуется, поскольку вы демонстрируете свою логику в виде открытого текста. Таким образом, любой, кто имеет доступ к физическому серверу, может связываться с вашим кодом, и вы никогда этого не заметите. Вы можете попытаться создать предварительно скомпилированный веб-сайт, но в итоге вы получите много dll и почти неприкасаемых aspx файлов. Microsoft признала это ограничение и выпустила инструмент Web Deployment Project.

2) Вам необходимо отслеживать, что вы изменили локально и что вы загрузили на рабочий сервер. Там нет контроля версий. Visual Studio имеет инструмент Web Copy, но этот инструмент не помогает. Мне пришлось создать свой собственный инструмент, который отслеживал изменения на основе Visual Source Safe.

3) Когда вы нажимаете F5 для выполнения отладки, компиляция и выполнение всего проекта занимает всего 2 минуты. Конечно, вы можете присоединить отладчик к существующему потоку, но это не очевидное решение.

4) Если вы когда-нибудь попытаетесь сгенерировать элементы управления на лету, вы получите первое неразрешимое ограничение. Как ссылаться на другие страницы и элементы управления. Компиляция страниц и элементов управления происходит отдельно для каждого каталога. В лучшем случае вы получите сборку для каждого каталога, в худшем - каждая страница или элемент управления получат свою собственную сборку. Если вам нужно сослаться на другую страницу из элемента управления или другую страницу, вам нужно явно импортировать ее с помощью директивы @Reference.

Так что,

customControl = this.LoadControl ("~ / Controls / CustomUserControl.ascx") как CustomUserControl;

Тебе нужно,

Но что, если вы хотите добавить что-то действительно динамически и не можете поместить все соответствующие директивы @Reference? Или Что, если вы создаете серверный элемент управления, и у него нет файла ascx, поэтому у вас нет места для @Reference? Поскольку каждый элемент управления имеет свою собственную сборку, отражение практически невозможно.

Проекты веб-приложений, которые вновь появились в Visual Studio 2005 SP1. Они решают все проблемы, упомянутые выше.

1) Развертывание. Вы получаете только одну DLL на проект. Вы можете создавать распространяемые пакеты и повторяемые сборки. У вас могут быть версии и сценарии сборки.

2) Если вы изменили код, вы можете загрузить только одну DLL. Если вы сделали изменение aspx, вы можете загрузить только изменение aspx.

3) Выполнение занимает максимум 2-3 секунды.

4) Весь проект находится в одной сборке, что помогает ссылаться на любую страницу или элемент управления. Заключение. Для любой серьезной работы вы должны использовать проекты веб-приложений. Отдельное спасибо Рику Стрэлу за его замечательную статью «Компиляция и развертывание в ASP.NET 2.0.

»

Answer 3

Я согласен с Ричем.

Дополнительная информация:

1. Развертывание вашего кода SOURCE, в том числе файлов .vb, на сервере - ПЛОХАЯ идея. Скомпилируйте это. Запутывайте, если можете, только не используйте прямой источник. Представьте себе злоумышленника, который получает доступ к системе. Они могут легко изменить ваш код, и вы можете даже не заметить. Да, вы можете использовать такой инструмент, как рефлектор для декомпиляции. Но действительно сложно декомпилировать полный сайт, внести необходимые изменения и вернуть их в производство.

2. Развертывание одного файла вполне может вызвать проблемы определенного типа в связанном модуле. Я предполагаю, что вы, ребята, на самом деле не делаете QA. Скажите им, что пора взрослеть.

3. Компиляция вашего сайта уменьшит JIT (как раз вовремя) компиляцию. Подумайте производительность.

4. Я также собираюсь предположить, что почти у всех есть доступ к производственному серверу. Это плохо с точки зрения компании, так как у вас нет контроля. Что происходит, когда работник решает устроить какой-то хаос перед уходом?

5. То, что вы описываете, соответствует кодировке Cowboy. Конечно, весело спешить на помощь, но этот стиль часто взрывает все.

Answer 4

Какая наилучшая стратегия развертывания во многом зависит от того, в какой среде вы работаете, и с какими разработчиками вы работаете.

Художники-визуалисты, которые начинали с графического макета и работали над программированием, гораздо больше подходят для создания и выпуска отдельных страниц. Также файлы .aspx.vb - это просто сценарии на стороне сервера, а не программирование.

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

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

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

Answer 5

У нас была эта дилемма, и мы решили использовать скомпилированную версию в основном из соображений безопасности. Если ваш сайт является внешним, вы могли бы поставить под угрозу свою безопасность, позволяя файлам VB находиться там в виде простого текста. Я понимаю, что можно было бы получить ваш код, если бы они действительно этого хотели, но это было бы дополнительным препятствием, которое им пришлось бы пройти. Если вы используете Visual Studio в качестве среды разработки, вы можете опубликовать предварительно скомпилированный сайт и проверить опцию именованных сборок при публикации, и это, по сути, создаст dll для каждой страницы aspx, так что вы можете сделать одноразовые изменения при необходимости. Это была отличная особенность, которую мы нашли, поскольку мы постоянно обновляли весь сайт, и были моменты, когда что-то обновлялось, чего не должно быть. После использования этой функции у нас больше не было обновлений, которые не должны появляться. Что касается отката, я надеюсь, что вы используете какой-то тип системы управления версиями / контроля версий. Team Foundation Server отлично подходит для управления версиями / исходным кодом, но он довольно дорогой.

Answer 6

Это плохо для отката. Если вы развертываете как веб-сайт против веб-приложения, да, вы можете сделать быстрые исправления одного или двух файлов, но что если вам когда-нибудь понадобится откат к предыдущей версии? Удачи в отслеживании всех файлов, которые были обновлены, чтобы сделать новую версию. Я очень предпочитаю концепцию «версии» по организационным причинам, и скомпилированное веб-приложение гораздо больше соответствует этому, чем проект «веб-сайт».