@Duydyv

Собственно, возник вопрос: "Как лучше настроить процесс обновления рабочих баз на одном сервере с сервера разработок?"
Ситуация следующая: На одном Домино-сервере находятся, непосредственно,рабочие базы и шаблоны с которых они обновляются. На другом "рабочие шаблоны" в которые постоянно вносятся какие то изменения и необходимо чтобы эти изменения, в тот же день происходили и с шаблонами рабочих баз. Ситуация осложняется тем, что дизайн базы разработан так, что в ней имеются настроечные документы, которые также меняются.

Приблизительное решение, пока ,видится следующим:
1. На рабочем сервере, скажем, в одной папке рабочая база, которая наследует дизайн(inherit design) с дизайн теплэйта с именем "Work template"
2. В другой шаблон, в формате nsf(не ntf), который является Master c еменем "Work template" и сдругой стороны наследует дизайн с шаблона "Dev template"
3. На сервере разработок лежит шаблон(также nsf) который master c именем "Dev template"
4. При необходимости внесения изменений в шаблон, разработчик,на сервере разработок, делает Replace Design c базы шаблона ,на базу ,которая уже находится в какой-то типовой конфигураци окружения.

И тут возникают вопросы:
1). Можно ли сделать так ,чтобы база в формате "nsf" отображалсь в диалоге выбора темплаэтов при выполнении операции "Replace Design"
2). Каким образом осуществлять обновление шаблонов между серверами в разных доменах. С помощью репликаций? Тогда можно ли настроить, каким-либо образом репликацию, чтобы скажем реплицировался только дизайн или документы определенного формата? Или можно каким-либо образом сконфигурировать по рассписанию задачу Design между двумя серверами?

Все мои вопросы упираются, элементарно, в незнание следующих:
а) Что происходит при репликации и какие есть ньюансы?
б) Чем принципиально различаются Replace design от Refresh design
в) refresh design это часть репликации или они функционально различаются.

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

0

@K-Fyry

1) Вроде нет, нельзя.
2) Обновление шаблонов с помощью репликации.

а) при репликации реплицируются изменения Нюансов тьма тьмущая, даже не хочется вспоминать...
б) Реплейс дизайн - эта полная замена дизайна из базы шаблона. В том числе можно заменить дизайн на вообще совершенно левый Рефреш - обновление дизайна, т.е. обновятся только те элементы которые изменились.
в) Различаются совершенно. Рефреш дизайна происходит с шаблона который репликой быть не должен.


А вообще стандартная схема такова:
1. Есть Dev шаблон. На сервере у разработчика.
2. Есть Production шаблон. На сервере у разработчика, плюс реплика на сервере заказчика.
3. Разработчик изменил что-то в базе, и решает выкатить версию. Он временно (!) ставит в Production шаблоне чтобы тот наследовал изменения с Dev-шаблона. Затем делает рефреш дизайна ручками. Убирает в Production шаблоне чтобы тот наследовал изменения с Dev-шаблона.
4. Сервер по расписанию реплицирует изменения Production шаблона на сервер заказчику.
5. На сервере заказчика по расписанию происходит рефреш основной рабочей базы с Production шаблона.
6. Если требуется в рабочей базе у заказчика запускаются некие скрипты для конверсии данных.
7. Процесс закончен.

Если надо обновить еще и некие документы настроек, то тут еще чуток всё усложняется. Надо в Dev-шаблоне иметь некий скрипт (или руками), который перенесет изменившиеся настройки в Production шаблон, и затем в рабочей базе тоже иметь скрипт который будет запущен и перенесет изменившиеся настройки в эту рабочую базу.

0

@Duydyv

Огромное спасибо.

0

@kROMyto

А как тогда в такой схеме решается проблема подписи серверных агентов от имени сервера заказчика???
Ведь ваша реплика подписана именно вашим сервером.

0

@K-Fyry

<!--QuoteBegin-GROMILA+19:03:2007, 14:51 -->
<span class="vbquote">(GROMILA @ 19:03:2007, 14:51 )</span><!--QuoteEBegin-->А как тогда в такой схеме решается проблема подписи серверных агентов от имени сервера заказчика???
Ведь ваша реплика подписана именно вашим сервером.
[snapback]59463" rel="nofollow" target="_blank[/snapback]?[/quote]

Да, про этот момент я забыл упомянуть. Есть маленький скрипт который подписывает все агенты. Если у нас есть админский ид клиента, то подписываем сами после наката дизайна на Production шаблон.
Если нету (по каким то секьюрным соображениям), то клиент запускает этот скрипт у себя на сервере сам.

0

@kROMyto

Плохо это - делать подпись после внесения изменений в систему!!!
У нас, например, много документооборотистых круглосуточных задач.
Если подпись делать после обновления дизайна/репликации, то существует промежуток времени, когда может агент не отработать из-за прав и произойдет СБОЙ
Вероятность сбоя увеличивается, если скрипт запускает заказчик сам, так как промежутов времени велик!!!

Мы просто поставляет шаблоны, которые следует подписать и уже потом обновлять базы
Сей процесс полностью поддается автоматизации на скриптах.

0

@Duydyv

<!--QuoteBegin-GROMILA+22:03:2007, 13:28 -->
<span class="vbquote">(GROMILA @ 22:03:2007, 13:28 )</span><!--QuoteEBegin-->Сей процесс полностью поддается автоматизации на скриптах
[snapback]59815" rel="nofollow" target="_blank[/snapback]?[/quote]

Каким же образом скриптом переподписываете дизайн? Точнее каким образом отлавливаете момент завершения репликации. Или у вас работает агент по расписанию?

0

@kROMyto

У нас репликация не используется!!!
Я говорил о другом способе - обновление через шаблон базы.
Есть шаблон (сформирован или сразу разарботака в шаблоне идет)
Шаблон отправляется заказчику (предварительно скрываем дизайн)
Заказчик должен:
1. Подписать шаблон
2. Обновить свою базу по этому шаблону

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

0

@Duydyv

<!--QuoteBegin-GROMILA+23:03:2007, 13:26 -->
<span class="vbquote">(GROMILA @ 23:03:2007, 13:26 )</span><!--QuoteEBegin-->Шаблон отправляется заказчику (предварительно скрываем дизайн)
Заказчик должен:
1. Подписать шаблон
2. Обновить свою базу по этому шаблону
[snapback]59949" rel="nofollow" target="_blank[/snapback]?[/quote]

Неее, так не пойдет...
А что если обновления выходят каждый день??? И в составе системы шаблонов эдак 15? И скажем необходимо выполнять оперативные обновления на этапе внедрения, когда процесс сопровождения полностью еще на исполнителе, а сотрудники заказчика еще только обучаются. Хорошо когда заказчик по боком или хотя бы в этом же городе, а если скажем в другой стране?...
Лично для себя я пока отработал следующую схему. На нашем сервере главные шаблоны которые реплицируются на сервер заказчика. Таким образом у заказчика также есть шаблоны с которых он затем при необходимости делает Refresh на рабочие базы. Причем ACL шаблонов на нашем сервере настроена так, что фактически репликация идет в одностороннем порядке от нас к заказчику.
При желании заказчика изменения вносятся нашими разработчиками, реплицируются на сервер заказчика (например, по расписанию). Затем мы звоним ответственному лицу - администратору, и просим сначала переподписать шаблоны главным сервером, а затем выполнить рефреш баз.... Впринципе, вещь вполне тривиальная даже для начинающего администратора (я уж не говорю об экономии времени и трафика Но... хотелось бы полностью избавиться от человеческого фактора в данной схеме(со стороны заказчика)... Поэтому вопрос открыт......

0

@kROMyto

Только вот постоянный коннект нужен.



Ну так а что мешает вам запрограммировать процесс подписания и обновления баз, закрепить за ним кнопку и дать ее в руки заказчику?
Или посылать заказчику письмо с особой темой, при получении которого автоматом стартует процесс подписания и обновления баз?

0

@kROMyto

И еще...

Мне кажется, что в вашей схеме репликации существует опасность бесконтроьного автоматического внесения изменений в реальные базы.
Как Вы гарантируете что админп не выполнит наследование до подписания реплицированных шаблонов администратором?
для этого флаг Inherit должен быть сброшен или не должно быть достпа к шаблонам у реальных баз.
Получается администратор должен делать Вкл/Выкл флажка?

Вы данную схему на практике исползуете?

0

@Duydyv

<!--QuoteBegin-GROMILA+23:03:2007, 20:09 -->
<span class="vbquote">(GROMILA @ 23:03:2007, 20:09 )</span><!--QuoteEBegin-->Вы данную схему на практике исползуете?
[snapback]60002" rel="nofollow" target="_blank[/snapback]?[/quote]

Вот именно по причинам, которые вы описали выше, пока не используем, а только отрабатываем.

<!--QuoteBegin-GROMILA+23:03:2007, 19:41 -->
<span class="vbquote">(GROMILA @ 23:03:2007, 19:41 )</span><!--QuoteEBegin-->Только вот постоянный коннект нужен.
[snapback]60000" rel="nofollow" target="_blank[/snapback]?[/quote]

Не совсем понял, какая здесь может быть проблема?

<!--QuoteBegin-GROMILA+23:03:2007, 19:41 -->
<span class="vbquote">(GROMILA @ 23:03:2007, 19:41 )</span><!--QuoteEBegin-->Ну так а что мешает вам запрограммировать процесс подписания и обновления баз, закрепить за ним кнопку и дать ее в руки заказчику?
Или посылать заказчику письмо с особой темой, при получении которого автоматом стартует процесс подписания и обновления баз?
[snapback]60000" rel="nofollow" target="_blank[/snapback]?[/quote]
Это не исключает человеческий фактор. Хотя, согласен, упрощает.



Тем не менее, схема, описанная мною выше, значительно удобнее "контейнерного" обновления шаблонов. Хотя бы потому ,что она срезает многие углы, которые, потенциально, могут стать причиной сбоя:
1. Администратору не требуется доступ к ОС, все действия выполняются из Notes
2. Нет необходимости заново корректировать ACL
3. Нет необходимости запоминать где расположены шаблоны и какие у них названия.
4. и прочее.

0

@kROMyto

В моих базах этого было достаточно, чтобы отказаться от применения репликации.
На мой взгляд, репликацию следует применять для распространения изменений и данных внутри единой системы.
Если необходимо обновлять систему, то лучше для этого готовить шаблон.

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

Лично я буду сеи проблемы решать на скриптах, если потребуется, а репликацию для этих целей не буду использовать, разве что для снижения траффика возможно, но это лишь вопрос передачи данных.

0