Разработка SharePoint / Производственная среда

Question

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

Как некоторые из вас, другие разработчики SharePoint, справляются с этим ограничением?

Answer 1

Существует действительно два (больше?) Уровня для «разработки» SharePoint. У вас есть код, который развертывается на сервере, например веб-части, типы контента, действия рабочего процесса и т. Д. Это относительно хорошо работает с точки зрения развертывания и передовых методов.

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

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

Затем у нас есть другой сайт, который сильно настроен с помощью дизайнера SharePoint, и тот, над которым мы работаем в прямом эфире.

Answer 2

Вы можете использовать Content Deployment Wizard (http://www.codeplex.com/SPDeploymentWizard) для быстрой миграции таких объектов, как списки и библиотеки. Вы также можете сделать резервную копию / восстановить производственную копию, затем внести изменения в нее, а затем рано утром часов, замораживание контента (надеюсь, никто не будет заботиться об этом), импорт всех измененных данных из производства в вашу копию, а затем восстановление копии в производство. По крайней мере, замораживание может быть отложено и будет необходимо только на время процедуры экспорта-> импорта-> восстановления.

На практике я просто делаю производственные изменения вручную.

Answer 3

Используйте код FeatureActivation для развертывания изменений в полях списков. После того как код обновит поля, вы деактивируете функцию и удалите ее. Это позволяет тестировать результаты в среде QA заранее.