Чтобы информация о проекте в MS Project Server была доступна не только менеджеру, но и другим участникам проекта, он должен быть опубликован. Это естественная и понятная особенность сервера управления проектами от Microsoft. Но из нее логично следует и другая особенность: чтобы участники проекта обладали актуальной информацией о его изменениях, он должен публиковаться регулярно, — желательно, после каждого изменения. И здесь уже начинаются проблемы. Именно поэтому автоматизация публикации — одна из доработок Project Server, наиболее востребованных его пользователями. Тем не менее, Microsoft так и не создал встроенных в Project Server средств для решения этой задачи.
Существует несколько подходов, по которым может строиться решение, и естественно, ни один из них не идеален. Опишем их преимущества и недостатки.
1. Обработка событий Project Server
Администратор Project Server может настроить обработчики событий на странице «PWA → Параметры сервера → Действующие политики → Обработчики событий на сервере». Сам обработчик, естественно, должен быть написан программистом в Visual Studio, собран как DLL и установлен в GAC.
При выборе конкретных событий, после которых будет происходить публикация, есть простор для фантазии. Представитель технической поддержки Microsoft рекомендует использовать Statusing.OnApplied, чтобы публикация происходила после каждого принятия обновлений. Также можно обрабатывать Project.Saved для автоматической публикации после каждого сохранения проекта.
Недостаток такого решения — существенное увеличение нагрузки на Project Server, ведь публикация является ресурсоемкой операцией. Должен быть запас по производительности у всей инфраструктуры фермы серверов SharePoint. Но более существенная проблема — при этом способе автопубликации не происходит пересчет формул в проектах (в 2007-й версии сервера), а также не обновляются связанные проекты.
2. Регулярная публикация по расписанию
Основное преимущество этого подхода — публикация может выполняться в нерабочее время, когда пользователи не создают нагрузку на сервер. Также, проще организовать настройку правил публикации, которые могут быть следующими.
- Запрет публикации проектов, которые еще ни разу не публиковались. Логично, что все подряд черновики не надо делать общедоступными.
- Публикация только тех проектов, которые имеют определенное значение какого-то корпоративного поля.
- Публикация проектов, принадлежащих только определенным пользователям, или ветвям СДРес.
2.1. Запуск публикации через PSI
Не столь важно, как будет технически реализована утилита для публикации. Есть возможность даже написать скрипт на PowerShell. Но поскольку лучше не публиковать все проекты подряд и иметь возможность гибко настраивать правила публикации, удобнее оформить утилиту как консольное приложение, запускаемое по расписанию, или как службу Windows.
Применение этого подхода позволяет избавиться от части проблем, возникающих при публикации по событиям. Но точно так же может не происходить пересчет формул, и не обновляются мультипроекты.
2.2. Публикация с помощью Project Professional
Есть возможность запуска по расписанию Project Professional, который будет снабжен надстройкой, выполняющей открытие проектов с сервера и их последующую публикацию. Надстройка может даже отслеживать связанные проекты и публиковать их.
Недостаток такого решения — в его сложности: нужно взаимодействовать не только с PSI, но и с объектной моделью настольного Project. Также это не всегда надежно: в интерфейсе Project может открыться диалоговое окно, которое переведет приложение в режим ожидания действий пользователя. Тогда автоматический процесс публикации остановится.
Как вы видите, спектр способов реализации автопубликации достаточно широк, и компания, эксплуатирующая Project Server, должна выбирать свой, исходя из конфигурации и устоявшихся практик управления проектами в организации. Мы же можем помочь в воплощении выбранного варианта.
