Среда разработки / производства SharePoint

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

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


sharepoint
person senfo    schedule 24.10.2008    source источник
comment
Любые обновления после недавних изменений в Sharepoint   -  person F11    schedule 20.03.2016

Ответы (3)


arrow_upward
3
arrow_downward

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

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

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

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

person Eugene Katz    schedule 24.10.2008

arrow_upward
1
arrow_downward

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

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

person Community    schedule 24.10.2008

arrow_upward
0
arrow_downward

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

person webwires    schedule 24.10.2008