Работа в команде нескольких разработчиков SharePoint

Question

В команде нескольких разработчиков лучше всего создать среду разработки?

У каждого есть своя собственная полная установка SharePoint, или обмениваться базами данных контента, или что -то еще?

Answer 1

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

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

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

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

Answer 2

Отличный вопрос! Удивлен тем, как мы все, кажется, до сих пор согласны. Это общепринято, которая может много разделить людей :-)

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

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

Мне также нравится иметь местный «сайт POC», который я могу сделать с тем, что я хочу. Я использую его для выполнения небольших тестов и прочего, я бы не стал делать на сервере разработки своего проекта. Если это становится слишком грязным, я всегда могу перезагрузить снимок.

Чтобы избежать вопросов «сработало на моей коробке», должны быть руководящие принципы о том, как разработать. Как иметь наименее возможные привилегии на коробке при разработке, и особенно с разрешениями посетителей только при выполнении нормальной разработки веб -части или аналогичной.

Серверы разработки должны создаваться с помощью того же золотого изображения и той же (предпочтительно сценариев) конфигурации с нулевой точкой, что и серверы Dev Test, Integration Test, Pre Prod и Prod. Это сведет к минимуму проблемы в тесте DEV из -за специальной конфигурации или программных проблем на сервере разработчиков. Я даже знаю о командах разработчиков (например, Бен Робб), которые удаляют все их виртуальные серверы разработчиков каждую неделю и разворачивают снимок (автоматизированный с PowerShell) сервера, чтобы сохранить серверы разработки как можно ближе к тестированию DEV (и другим средам), насколько это возможно Анкет

Часто упускается из виду, особенно для более крупных команд вам нужны руководящие принципы о том, каким должно быть именование (например, под папки в корневой папке (12hive, если хотите), как использовать пространства имен и т. Д.), Как развернуть (bin + cas или gac, а когда Используйте что), использование общей утилиты, как библиотеки. Не прояснившись до того, как запуск приведет к вам горе по дороге и увеличит риск наличия небольших островов кода, которые должны были/могли быть повторно использованы по всей команде (или даже в процессе, если библиотеки хороши и достаточно общие).

Answer 3

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

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

Answer 4

Заставляя разработчиков иметь свою собственную виртуальную машину, заставляет их писать код, который можно развернуть в команде Membes в их собственной виртуальной машине ;-) Это хитрость за отличный конечный результат!

Многие организации делятся SQL Server с различными базами данных контента и имеют отдельные виртуальные машины с SharePoint, Visual Studio и т. Д. Для каждого разработчика. Часто эти виртуальные машины фактически размещаются на общем хосте виртуализации, а не на рабочих станциях разработчиков из -за требований к памяти и т. Д.

@Spdevwiki's Создание среды развития SharePoint на этом.