Продвижение сайтов MOSS '07 от разработки до производства - PullRequest
5 голосов
/ 23 октября 2008

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

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

Кто-нибудь знает, существует ли стратегия управления для разработки SharePoint? Я читал в Интернете, что мы можем сделать резервную копию среды разработки и восстановить на производственном сервере. Это может сработать в первый раз, но любые обновления на рабочем сервере не могут этого сделать без риска потери данных на рабочем сервере. Я видел некоторые инструменты для переноса содержимого списка, страниц и документов с одного сервера на другой - хотя, по общему признанию, я еще не исследовал их.

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

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

Заранее спасибо,

Dan


Спасибо за быстрый ответ.

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

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

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

Там есть очень мало документации для такого рода вещей. Похоже, что все, что я читаю, - это как изначально настроить сервер SharePoint, а не управлять им в долгосрочной перспективе.

Есть ли у вас какие-либо советы или предложения?


Спасибо всем за ваши предложения.

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

Итак, первоначальное развертывание в значительной степени установлено. То, что я ДЕЙСТВИТЕЛЬНО надеюсь выяснить, - это то, как я могу обновить такие вещи, как типы контента и столбцы, и прочее в будущем. Можно ли изменить типы контента после их использования? Потому что, судя по моим первоначальным испытаниям, это кажется невозможным. Я не беспокоюсь о сборках, потому что похоже, что они меняются просто отлично, но единственный способ, которым я обновил тип содержимого, - это удаление любых элементов, ссылающихся на них (то есть всех страниц в моей библиотеке страниц), удаление тип содержимого, затем добавьте его заново.

Кто-нибудь из вас знает, есть ли способ обновить тип контента ПОСЛЕ первоначального развертывания? ... когда пользователи уже создали элементы на основе типов контента, которые мы уже развернули?

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

Ответы [ 5 ]

5 голосов
/ 23 октября 2008

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

Осталось только активировать эти функции. Таким образом, вы можете постепенно внедрять новые функции без необходимости делать все на производстве.

WSPBuilder - это приложение, которое помогает вам создавать WSP.

Для автоматизации всего этого ... удачи. Здесь много работы.

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

Мы пытались, и это невозможно сделать нормально с помощью функций. Это должно пройти через то, что я называю «развертывание с кодом».

2 голосов
/ 24 октября 2008

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

Я предпочитаю STSDev для развертывания решений с использованием пользовательских типов контента.

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

Для общедоступного сайта вам необходимо использовать Развертывание контента

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

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

Я не согласен с этим. Развитие происходит на медленнее, если вы не знакомы с функциями, но как только уровень знаний достигнут, это не является основным фактором.

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

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

1 голос
/ 24 октября 2008

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

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

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

У разработки в SharePoint есть свои проблемы, что само собой разумеется, но пока Я обнаружил, что преимущества перевешивают проблемы.

Командная разработка в Microsoft Office SharePoint Server 2007

1 голос
/ 23 октября 2008

Я рекомендую взглянуть на последний пост Криса О'Брайенса и его замечательного Мастера развертывания контента: это не все о возможностях!

0 голосов
/ 06 ноября 2008

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

Для перемещения текущего контента из QA в Prod мы используем Echo

...