CVS-системы в Domino

[Кирилл Шваб]

Yakov,

респектую за подробное описание. ;-)

Кстати, для GIT вроде можно плагин поставить в дизайнера и работать через GUI (кому-то может будет удобней).
Документ с описанием/скриншотами прикрепляю к сообщению, оригинальное сообщения из блога Sean Cull:

Ссылка скрыта от гостей

P.S.

А мы на работе пока "промышленно" СКВ/СУВ не развернули (используем Redmine и Mercurial) - только пара разработчиков пока пользуется, поэтому и описывать особо нечего.
;-)

 

[turumbay]

Кстати, для GIT вроде можно плагин поставить в дизайнера и работать через GUI (кому-то может будет удобней).

Ага. Проект на OpenNTF

Ссылка скрыта от гостей

 

[Nosferatus]

Собственно вопрос в теме.
Как организовать работу по командной разработке? В Дизайнере наткнулся на Team Development, до конца так и не разобрался как можно организовать работу, нужен ли дополнительно устанавливать SVN сервер, то какой (установил VisulSVN Server - но он не понял лотусовый формат)?

А задача заключается в следующем: С минимальными трудозатратами объединять доработки одной БД порядка 3-5 разработчиков, которые параллельно реализуют поставленные им задачи. При этом разработчиков можно разделить на 2 группы: свои и аутсорсеры.

Есть ли у кого опыт командной разработки в Лотусе? И как технически облегчить работу по сведению всех доработок в одну БД?

PS Буду признателен за любую подсказку.

 

[savl]

Единственный SVN для лотуса, который знаю:

Ссылка скрыта от гостей

NSF это хранилище, в нутрах его элементы дизайна - документы со своей спецификой, поэтому svn и не понимает.
Из справки дизайнера понял, что контроль версий возможен только для проекта на диске, и вот уже к этому проекту можно подключить SVN.
раздел справки: {Lotus Domino Designer User Guide > Administering applications > Source control in Domino Designer}
Там много инфы.

Без контроля версий:
Если разделить задачи, то два разработчика не должны править один элемент дизайна.
Сначала решают какие модули/классы/функции/представления/формы нужны, затем один правит/создает формы, другой библиотеки, третий агенты, четвертый представления.
Опять собираются еще раз пересматривают, и по новой до завершения работы.
Затем один все это проверяет на качество кода (в идеале), правят в случае необходимости.

P.S. На прошлой работе было 40+ программистов, по 3 на базу, задачи разные, а элементы одни.
Сначала делали разработку каждый в своем шаблоне, версионность так сказать.
Затем под присмотром архитекторов сливали в один шаблон для наката. Работало нормально, но сроки затягивались.
Затем купили teamstudio, около 3х месяцев настраивали, разбирались.
И я успел с ней поработать, ровно 2 недели, так как уже увольнялся, нюансов всех не знаю, но странная она.

 

[lmike]

чао не нра...
для 8.5.2+ можно использовать любые ср-ва коллективной работы, с нек. особенностями
версией нотуса обусловлена фича Team Development здесь уже описывали работу в таком режиме

 

[VladSh]

5 копеек в тему.
Сейчас работаю в конторе, где командная разработка для меня, привыкшего к работе по старинке, на высоком уровне.
Все разрабы работают на локале на виртуалках: создаёшь сколько душе угодно - разные пересечения ОС и версии Лотуса, и работаешь хоть в нескольких параллельно.
Из-за того, что фича "Team Development -> тра-ля-ля" выгружает полный xml с кучей ненужной ботвы, то она не используется.
Вместо этого 2 агента: экспорт и импорт (xslt). Экспортируются только нужные тэги dxl, что касается библиотек и агентов, то всё ненужное вырезается по максимуму, чтобы было удобно сравнивать код в diff, а не весь dxl.
Экспортируется код в определённое место в файловой системе, которое отслеживает TortoiseSVN. Сравниваешь; можно просмотреть кто коммитил изменения, если что, отменить свои Revert'ом или закоммитить. Когда коммитишь, то указываешь номер тикета из Jira (в качестве багтрекинговой системы используется именно она) и описание, какие изменения внёс. После коммита в соотв. Jira-тикете появляется ссылка на коммиты по нему и файлы, которые изменились. Очень удобно. Подробности всего, как это настраивается, не знаю, не до этого сейчас.
Импортируются все последние изменения, приезжающие из SVN'а, также агентом.
Точно также, с помощью dxl-импорта/экспорта работают инсталляторы, причём кастомизируются базы клиентов учитывается их код, безболезненно добавляя наш, т.е. очень глубокий анализ. Шаблоны ntf вообще не используются. Похоже работает локализация на разные языки. Деинсталляция работает также - восстанавливает исходное состояние, вычищая чисто наш код.
Короче я многость обалдевший от всего этого)

 

[lmike]

VladSh хватаетли чистого ДХЛ или приходится пинать СиАПИ?

 

[VladSh]

На сколько я понял, в инсталяторе/деинсталяторе используется NotesAPI для того, чтобы заимпортить 2 агента ("инсталятор" и "деинсталятор") и толкнуть их, а они уже всё сворачивают и разворачивают. Так сделано, чтобы не усложнять инсталятор, и потому, что пакеджи (в т.ч. и dxl) запрашиваются с сервера, и состав старых версий (чтобы корректно откатить изменения) и новых.
Внутри агенты работают без API, с помощью ActiveX MS-XML/XSLT, но как мы знаем, это можно было бы сделать и родными средствами.

 

[Кирилл Шваб]

VladSh

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

Экспортируется код в определённое место в файловой системе, которое отслеживает TortoiseSVN.

Т.е. с виртуалок разработчиков изменения выгружаются своими обработчиками в единое место (например, на сетевой файловый ресурс), к которому прикручена система контроля версий, а с него уже код попадает в "основную" базу. Так?

 

[VladSh]

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

Тут возникла идея, а что если просто переписать кусок в

Ссылка скрыта от гостей

, встроенный в Domino Designer, отвечающий за экспорт и импорт? Начал искать исходники и не нашёл...(

Ещё парочка интересных ссылок:

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

.

 

[Кирилл Шваб]

VladSh

Тут возникла идея, а что если просто переписать кусок в Source Control Enablement, встроенный в Domino Designer, отвечающий за экспорт и импорт?

В виде плагина думаю такое бы много кому пригодилось.

Начал искать исходники и не нашёл...(

Думаю что для доступа к исходникам там надо быть

Ссылка скрыта от гостей

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

Ссылка скрыта от гостей

. ))

 

[garrick]

Я так понимаю, специально для любителей DXL и всяких source version control system

Support for "Headless" Designer - A command line build system has been added to Domino Designer to let you build NSF and NTF files from source code repositories. You may use either a single command method or a command file method. Refer to the Source control sections of this guide for more information.

 

[VladSh]

Коллеги, Swiper'ом кто-то пользовался? Всё похоже сделано как и я хотел - можно указать свой xslt-файл.
Есть некоторые проблемы после импорта, наверное что-то режет не так (в последнем комменте есть ссылка на их xslt).

Вложил наши файлы (почему-то форум не захотел принимать с нормальными расширениями - переименовал все в txt).
Сначала к экспортированному файлу применялся dxl_as_is.xsl, затем dxl_transform_clean.xsl (почему ребята разбили на 2 файла - не знаю, я писал лишь базею с настройками проектов и код загрузки/выгрузки), а потом ещё производилась корректировка регистра некоторых команд LS - файл fixCase.dat.
В dxl_transform_clean.xsl исправлено изменение размеров контролов на форме при открытии на мониторе с другим размером окна. Также был исправлен пересчёт pardef при их добавлении/удалении.
Что не успели тогда допилить - похожая проблема с изменением ширины колонок - указанное целое число потом преобразуется в дробное с кучей цифр после точки; можно при экспорте всегда округлять. Ну и ещё что-то было мелкое.

Думаю, что на основе этих файлов и того, что есть в проекте Swiper, можно собрать один рабочий, и потом его использовать в Swiper. Ну или декомпильнуть оригинальный Source Control и добавить несколько строк для выполнения xslt.

 

[oshmianski]

Я пробовал. Бросил.

В "чистом" виде, на мой взгляд не особо полезно.

Какая цель? Пилить полученный ODP в дгугой IDE? Контроль версий? Есть успешный промышленный опыт использования?

1. Без открытия дизайнера изменения все равно не подтянутся в дизайн бд.
2. Глюки, типа обновления pardef и ширин (возможно и другие), делают бесполезным для CSV.

 

[VladSh]

Какая цель? Пилить полученный ODP в дгугой IDE? Контроль версий?

Контроль версий.

Есть успешный промышленный опыт?

Естессно, - выше писал, да и вся тема об этом.

1. Без открытия дизайнера изменения все равно не подтянутся в дизайн бд.

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

2. Глюки, типа обновления pardef и ширин (возможно и другие) делают бесполезным для CSV.

Эти проблемы, как писал выше, на уровне форм были решены. Виды у всех обновляются редко, так что это не критично. Но даже это легко допилить, если соображать в XSL.

 

[savl]

@VladSh я использую и еще 11 человек, используем swiper (немного допилили), SourceTree + git.
вот запись доклада

Ссылка скрыта от гостей

 

[VladSh]

@savl
В 2012-13 годах в команде 4 разраба и один из них - проверяющий коммиты на SVN было гораздо проще. Ну и описываемых проблем по большей части не было, т. к. не использовали Java, XPages, PathTruHTML и web-сервисов. Но зато было много форм, где количество внедрённых видов доходило до 12-ти, и я что-то не помню проблем при импорте.
Проблемы были с общими действиями... У каждого из них нет какого-либо идентификатора (либо есть, но просто не экспортируется в dxl), и как Lotus запоминает, какое и куда вставляется, неизвестно. При импорте все общие действия сбивались, т.е. можно было наблюдать на формах зоопарк из них, - вместо реально вставленных отображались другие, с вообще других форм, ну и порядок вставленных менялся на случайный. Решили удалением "<sharedactionref...>" и "</sharedactionref...>" из выгруженного dxl форм и видов, а на импорт никогда не принимали общие действия, - благо можно было отдельно в xml настроить перечень элементов дизайна, которые экспортируются и импортируются.
И с формами проблему решили.
В целом было очень удобно!

Сейчас команда 2 разраба и Chiao, которое восстанавливает любой элемент дизайна без проблем. Но я не люблю восстанавливать, и забыл, когда в последний раз это делал. В Chiao свои недостатки - сравнение убогое и UI очень неудобный. Сейчас наоборот - много кода на Java и web-сервисов, что на Java, что LS...

> используем swiper (немного допилили)
Допилили xsl-шаблон или код самого Swiper'а? Выкладывали на github?
Можно ли там поэлементно настраивать, что экспортировать/импортировать?
Вообще мне очень мешает в RALS и в этих плагинах-экспортёрах то, что нет галки "Пропускать элементы дизайна, наследуемые из других шаблонов". Это громадный недостаток.

Можно сюда вложить презентаху? Было бы полезно. А то видео посмотреть, к сожалению, на один раз - на работе запрещена закачка, а дома место нужно под другое, - посмотрел и удалил.

 

[savl]

код самого Swiper'а

код и файл, не выкладывал. там изменения все в одном месте, файл src\org\openntf\swiper\action\FilterMetadataAction.java функция getFilteredInputStream
Это фактически одно место где все происходит, все остальное абстракции над плагинами дизайнера.

я там вот такие строки добавил:


Преза:

Ссылка скрыта от гостей

Все презентации RNUG

Ссылка скрыта от гостей

И еще: надо твои три файла попробовать сейчас соединить и натравить на какую-то из своих баз, посмотрю результат и отпишусь.
Возможно часть своих проблем поправлю, ну кнопки скорее всего точно.

Для меня сейчас основная проблема: java base class и html остальное пережить можно.

 

[savl]

@VladSh
я потестил файлики, сделал отдельный, который работает даже с изначальной версией swiper, без моих правок.
Но есть вот такое: лечится рекомпайлом, но тогда source/git отловит эти элементы как измененные.
Поля с суффиксами "_O" не удаляются, но это можно сделать.
В цикл копирования нод надо вставить условие:

<xsl:if test="not(starts-with(@name,'$') and (substring(@name,string-length(@name)-1,2) = '_O' or substring(@name,string-length(@name)-1,2) = '_0'))">

Я не такой знаток xslt, мне немного сложно...

Из плюсов: не нужны мои правки для кнопок/пробелов.
идея записывать Lotusscript в CDATA интересная, но лично для меня, это мне не важно, я проблем с этим не видел.

Файлик прикрепил, надо убрать .txt
Моя версия swiper + мой файл xslt вот тут

Ссылка скрыта от гостей

Там актуальная версия 2.0.4 вот ее надо ставить.
Исходный код моего форка: savlpavel/Swiper
Ведет сразу на ветку ButtonIssue , которая правит кнопки на подформах и формах, чтобы они не становились безумного размера.

 

[VladSh]

@savl
Круто! Думаю, люди оценят!
Сам пока не пользуюсь (у нас сейчас CIAO), но рад что хоть кому-то помогло!

Интересно, ситуация множественных изменений dxl при изменении форм улучшилась?