Добрый вечер. Случилось так, что я столкнулся с проблемой хорактера организации рабочих сред. И мне хочется это исправить.
Дело вот в чем, разработка наших решений производиться прямо на виртуальных серверах, ws2008r2 + vs2010 + sp2010.
В проекте есть несколько солюшенов, которые деплоятся прямиком в gac и на сервер sharepointa, у одного из солюшенов скоуп деплоя — web, у другого — site.
В итоге, так как на одном сервере работают несколько разработчиков невозможно друг-другу не мешать. wsp пакеты деплоящиеся от меня затрут wsp пакеты другого пользователя. Или если я буду тестировать процеуру деплоймента, то встанет весь сервер целиком, не важно сколько на нем работает пользователей, они попросту ничего не смогут сделать, так как я буду затирать их изменения.
Хочется это исправить. Хочу спросить профессионалов, как?
Как можно разграничить процесс разработки между разработчиками так, что бы они друг другу не мешали?
Что я делал. Я создавал две разные site-коллекции и разворачивая проект на однообнаруживал что и на второй присутствуют фичи из первого, просто они не активированы. Причем фичи имеют скоуп — web.
Если я пытаюсь сделать тоже самое на другой site-коллекции, то обнаруживаю, что такие пакеты уже установлены.
Что делать? Как быть? Подскажите пожалуйста?
Здравствуйте, -n1l-, Вы писали:
N>Добрый вечер. Случилось так, что я столкнулся с проблемой хорактера организации рабочих сред. И мне хочется это исправить. N>Дело вот в чем, разработка наших решений производиться прямо на виртуальных серверах, ws2008r2 + vs2010 + sp2010. N>В проекте есть несколько солюшенов, которые деплоятся прямиком в gac и на сервер sharepointa, у одного из солюшенов скоуп деплоя — web, у другого — site.
Похоже немного напутали. Solution можно задеплоить либо Globally либо на Web Application. Как возможный выход, теоретически ( сборки деплоить не в Gac а в папку bin, если получиться перенести ) и Solution делать Target To Web Application. Ну и естесвенно на каждого разработчика свой Web Application.
Я не буду сейчас говорить, что менять модель деплоймента из за отсутсвитя нормальной среды разработки это конечно же мягко говоря неправильно, думаю сами понимаете.
N>В итоге, так как на одном сервере работают несколько разработчиков невозможно друг-другу не мешать. wsp пакеты деплоящиеся от меня затрут wsp пакеты другого пользователя. Или если я буду тестировать процеуру деплоймента, то встанет весь сервер целиком, не важно сколько на нем работает пользователей, они попросту ничего не смогут сделать, так как я буду затирать их изменения. N>Хочется это исправить. Хочу спросить профессионалов, как? N>Как можно разграничить процесс разработки между разработчиками так, что бы они друг другу не мешали?
Ну я, конечно, не знаю, как там у профессионалов , но мы работали каждый в своей вируталке на локальной машине. Проблем гораздо меньше, начиная от разработки, деплоймента, экспирации паролей, loopback check и прочей фигни.
Да, но если делать стенд для демонстрации или тестирования, то мы столкнулись с тем, что иногда приходилось, удалять все данные из списков, библиотек и прочее при updat-ах ( например, если у вас изменился тип поля в списке ). Если это происходит часто, то часто приходится наполнять тестовый стенд тестовыми записями. Наши QA это сильно ненавидили, но как с этим боротся в тот момент мы не придумали.
N>Что я делал. Я создавал две разные site-коллекции и разворачивая проект на однообнаруживал что и на второй присутствуют фичи из первого, просто они не активированы. Причем фичи имеют скоуп — web.
Web feature в разделе Site Collection features не могут отображатся.
А так это вроде как правильное поведение, ведь у вас же Web features отображаются в каждом SPWeb-е в сайт коллекции. Почему бы каждой фичи с Site Collection Scope не отображаться в каждой сайт-коллекции в пределах одного Web Application?
N>Если я пытаюсь сделать тоже самое на другой site-коллекции, то обнаруживаю, что такие пакеты уже установлены. N>Что делать? Как быть? Подскажите пожалуйста?
Раскручивайте начальство на нормальное железо, ставте виртуалку и будет вам щасте.
Да на слабых машинах, иногда наблюдались time-out exceptions, когда некоторые службы SharePoint-а не успевали обработать запросы =).
Здравствуйте, -n1l-, Вы писали:
N>Хочется это исправить. Хочу спросить профессионалов, как? N>Как можно разграничить процесс разработки между разработчиками так, что бы они друг другу не мешали?
Надо каждому разработчику свою ферму.
Или отказаться от сольюшнов и делать apps, но это только 2013.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, -n1l-, Вы писали:
N>>Хочется это исправить. Хочу спросить профессионалов, как? N>>Как можно разграничить процесс разработки между разработчиками так, что бы они друг другу не мешали? G>Надо каждому разработчику свою ферму. G>Или отказаться от сольюшнов и делать apps, но это только 2013.
Здравствуйте, Engler, Вы писали:
E>Ну я, конечно, не знаю, как там у профессионалов , но мы работали каждый в своей вируталке на локальной машине. Проблем гораздо меньше, начиная от разработки, деплоймента, экспирации паролей, loopback check и прочей фигни.
Ну у нас тоже самое. Только лицензий мало, а людей больше раза в 2.
E>А так это вроде как правильное поведение, ведь у вас же Web features отображаются в каждом SPWeb-е в сайт коллекции. Почему бы каждой фичи с Site Collection Scope не отображаться в каждой сайт-коллекции в пределах одного Web Application?
Ну не совсем. Фича имеет скоуп веб, а при деплое на одну sitecollection, все фичи становятся доступны и в другой.
Все из-за гака, скорее всего, да, но как по другому?
N>>Если я пытаюсь сделать тоже самое на другой site-коллекции, то обнаруживаю, что такие пакеты уже установлены. N>>Что делать? Как быть? Подскажите пожалуйста? E>Раскручивайте начальство на нормальное железо, ставте виртуалку и будет вам щасте.
И так на виртуалках, но лицензии дорогие. Приходится 2ем на одной виртуалке работать.
Здравствуйте, -n1l-, Вы писали:
N>Ну у нас тоже самое. Только лицензий мало, а людей больше раза в 2.
А может некоторым достаточно будет SharePoint Foundation или всем обязательно полную версию?
Здравствуйте, Михаил Романов, Вы писали: МР>А может некоторым достаточно будет SharePoint Foundation или всем обязательно полную версию?
Для некоторых задач да, достаточно на локальном сервере что-то задеплоить и постестировать, но есть задачи и они часто пересекаются где нужно работать именно на сервере. Так как для этого нужна полная установка нашего решения, которое требет серверной интсаляции.
Здравствуйте, -n1l-, Вы писали:
N>Ну у нас тоже самое. Только лицензий мало, а людей больше раза в 2.
Trial на 180 ( вроде 180 дней ) не устраивает?
N>Ну не совсем. Фича имеет скоуп веб, а при деплое на одну sitecollection, все фичи становятся доступны и в другой. N>Все из-за гака, скорее всего, да, но как по другому?
Доступны == активированы, или доступны это просто видны в списке активации. Думаю врядли из за gac, но на скорую руку не нашел, как себя должны вести веб фичи между сайт коллекциями. Почему вы считаете, что ваше поведение не правильное?
E>>Раскручивайте начальство на нормальное железо, ставте виртуалку и будет вам щасте. N>И так на виртуалках, но лицензии дорогие. Приходится 2ем на одной виртуалке работать.
P.S: Как хак, можно посмотреть в сторону Hidden features и Activation Dependency , или управлять видимостью в Feature Receiver.
Здравствуйте, Engler, Вы писали: E>Trial на 180 ( вроде 180 дней ) не устраивает?
Проект слишком крутой для этого. Плюс все эти действия по переустановке затрачивают время.
Время — деньги. Так что вряд ли.
E>или доступны это просто видны в списке активации.
Именно, просто видны.
E>P.S: Как хак, можно посмотреть в сторону Hidden features и Activation Dependency , или управлять видимостью в Feature Receiver.
Непонял связи. Я, мой коллега вдвоем работаем над одним солюшеном, просто с разными фичами. И мы будем перетирать фичу друг-друга при разработке.
Я думаю о тестах. Так как прямая отладка из студии реально не подходит. Увы пока более простых и быстрых альтернатив нет, но...
E>>P.S: Как хак, можно посмотреть в сторону Hidden features и Activation Dependency , или управлять видимостью в Feature Receiver. N>Непонял связи. Я, мой коллега вдвоем работаем над одним солюшеном, просто с разными фичами. И мы будем перетирать фичу друг-друга при разработке.
Я решил, что проблема именно в том, что они еще и отображаются в др. сайт коллекции.
N>Я думаю о тестах. Так как прямая отладка из студии реально не подходит. Увы пока более простых и быстрых альтернатив нет, но...
Там я имел ввиду не об отладке, а об тестировании. Что бы можно было отлаживать нужно, что бы были разные w3wp процессы, а это может достигаться разными Web Application-s на одном и том же севрере. Но проблемка в том, что сборка в gac , если она деплоится действительно будет перетираться ( насколько я себе это представляю). Но если сборки будут в лежать в папке bin ( а для разных WA они разные ), то проблем не будет.... они будут в дргом
Методологически правильнее выделить среду разработки, тестирования и production.
Идеально локальная виртуалка. Мы так делаем.
Но если нет возможности — договоритесь между собой о правилах игры:
1. Именование пакетов и DLL — так чтобы не пересекались. Например ru.rsdn.SolutionName
2. ограничивать по возможности scope — Site.
3. Если условия позволяют — каждому программисту создать свой WebApplication в качестве песочницы, если не получится — хотя бы каждому по сайту.
4. Вбивать в свойствах солюшна что он делает и кто автор (чтоб лечге было искать нарушителей)
5. Консолидировать отлаженные решения в одном месте.
..... остальное зависит от методологии управления проектом.
, но мы работали каждый в своей вируталке на локальной машине. Проблем гораздо меньше, начиная от разработки, деплоймента, экспирации паролей, loopback check и прочей фигни.
