Коллективная разработка и управление артефактами в WebSphere Integration Developer v6.2

В данной статье рассматривается система управления исходными кодами и версиями модулей в WID v6.2. Это обновленная версия статьи "Коллективная разработка при помощи WebSphere Integration Developer и WebSphere Process Server", которая вышла в 2006 году и описывала версию WID v6.0.2. В качестве системы контроля исходных кодов мы используем Subversion.

Введение

В данном документе рассматриваются процедуры управления исходными кодами (source control management – SCM), имеющие отношение к WebSphere Integration Developer (WID) v6.2. Мы используем возможности коллективной разработки, имеющиеся в WID и Eclipse, а также механизм удаленного управления исходными кодами.

Мы начнем с обзора основ коллективной разработки и рассмотрим структуру модуля WID. Всесторонне рассматриваются процедуры, демонстрирующие взаимодействие с сервером Subversion в WID, включая основные элементы системы управления исходными кодами Subversion. Также исследуются более сложные темы, связанные с использованием Subversion.

Предполагается, что у вас есть некоторый опыт работы с WID и вы знакомы с основами системы управления исходными кодами. Данная статья основана строго на клиентском взаимодействии между WID и Subversion; конфигурация сервера – это тема повышенной сложности, которая выходит за рамки данной статьи.


Общий обзор проекта WID и совместной разработки

Структура проекта WID

Каждое WID-приложение состоит из SCA-модуля и необязательного набора зависимостей библиотеки сервисов. SCA-модуль содержит базовые артефакты, необходимые для развертывания и запуска приложения. К базовым объектам можно отнести, в частности, бизнес-объекты, интерфейсы, карты и бизнес-процессы. После развертывания и установки приложения на основе базовой логики артефактов генерируется Java-код.

Каждый SCA-модуль содержит также ряд сгенерированных промежуточных модулей (staging module). Поскольку промежуточные модули определяют JEE-зависимости и необязательное web-содержимое, обычно они не нуждаются в модификации пользователем. Так как промежуточные модули не содержат авторской BPM-логики, они не видимы в перспективе Business Integration, но видимы в перспективе JEE или Resource.

Названия промежуточных модулей основаны на базовых именах SCA-модуля. Например, предположим, что в рабочей области WID находится SCA-модуль HelloWorld. После создания SCA-модуля будут созданы следующие промежуточные модули:

  • HelloWorldApp
  • HelloWorldEJB
  • HelloWorldWeb
Рисунок 1. Промежуточные модули для WID-приложения
Рисунок 1. Промежуточные модули для WID-приложения

Отметим, что ModuleNameWeb будет создаваться только в том случае, если в SCA-модуле определена информация о связывании оконечной точки web-сервиса. В общем случае система управления исходными кодами отслеживает только SCA-модуль и зависимые библиотеки, но в некоторых случаях может потребоваться управление также промежуточными модулями.

Авторские и сгенерированные артефакты

Артефакты, созданные пользователем в WID, называются авторскими (authored). Если пользователь создает новый WSDL-интерфейс или бизнес-объект, в рабочей области (workspace) будет существовать соответствующий .wsdl- или .xsd-файл. В некоторых случаях один тип артефакта содержит несколько поддерживающих файлов. Например, при создании нового BPEL-процесса в рабочей области создаются несколько авторских файлов, включая файлы .bpel, .bpelex и Artifacts.wsdl. Каждый из этих файлов является авторским, поскольку все они необходимы для успешного создания модуля.

После создания модуля в WID для авторских артефактов в процессе развертывания генерируется Java-код. Сгенерированные артефакты обычно представляют собой Java-классы, основанные на логике, определенной в авторских BPM-артефактах. Так как сгенерированные артефакты не нужны во время развертывания, их не нужно контролировать в системе управления исходными кодами.

В WID v6.0.2 существовало много несогласованностей между авторскими и сгенерированными артефактами. Некоторые артефакты генерировались во время компоновки, тогда как другие – во время установки приложения. Этот процесс был значительно усовершенствован в WID v6.2, где все артефакты генерируются во время развертывания и установки приложения. Поэтому в SCA-модуле WID v6.2 отсутствуют сгенерированные Java-файлы.

В отличие от SCA-модулей, промежуточные модули является некоторым образом уникальными. Они появляются в рабочей области после создания SCA-модуля. По этой причине их не нужно контролировать в SCM, если только они не содержат специализированного содержимого или изменений в дескрипторе развертывания JEE. В случае добавления авторского содержимого в промежуточный модуль или изменения дескриптора развертывания JEE измененные промежуточные модули также нужно будет контролировать в системе управления исходными кодами, чтобы эти изменения можно было зафиксировать. При добавлении специализированного содержимого в промежуточный Web-модуль (например, HTML- или JSP-страниц) модуль ModuleNameWeb необходимо контролировать в удаленном репозитории управления исходными кодами. Чтобы избежать такой путаницы, рекомендуется создать отдельный Web-модуль для каждого специализированного содержимого вместо того, чтобы полагаться на промежуточный модуль ModuleNameWeb.

Унаследованные свойства против неунаследованных

С авторскими и сгенерированными артефактами тесно связаны свойства происхождения (derivation properties) артефакта. Артефакт может быть унаследованным или неунаследованным, что определяется в свойствах происхождения файла в окне Physical Resources или перспективе Resource, как показано ниже.

Рисунок 2. Свойства происхождения артефакта
Рисунок 2. Свойства происхождения артефакта

В некоторых SCM-продуктах, например CVS, свойства происхождения папки или файла определяют, контролируется или нет артефакт в SCM-системе. В то время как CVS игнорирует все унаследованные артефакты, Subversion не следует этой схеме. Каждый файл в рабочей области, независимо от его свойств происхождения, передается в репозиторий по умолчанию. В параметрах Subversion можно настроить фильтры для исключения файлов из системы управления исходными кодами. К счастью, в WID v6.2 в этом обычно нет необходимости, поскольку генерирование артефактов не производится до развертывания или установки приложения.

Унаследованные артефакты не появляются в SCA-модулях WID v6.2, поэтому свойства происхождения артефакта категорически не рекомендуется изменять. В предыдущих версиях WID свойства происхождения артефакта можно было менять без существенных последствий, но WID v6.2 менее снисходителен. Любой WPS-артефакт, свойство которого меняется на derived, немедленно удаляется из рабочей области механизмами компоновки WID. Это происходит потому, что WID понимает, что унаследованные артефакты генерируются, а сгенерированные артефакты должны присутствовать только во время развертывания и установки. Следовательно, если артефакт становится унаследованным, WID предполагает, что этот файл должен генерироваться и не должен присутствовать в рабочей области.

Урок очень прост: свойства происхождения для артефактов WID v6.2 строго задаются в первичном SCA-модуле и никогда не должны меняться.

Редактор развертывания модуля (и как он связан с модулем App)

В более ранних версиях WID изменения свойств развертывания модуля, например Web services security (система защиты Web-сервисов), и дескриптора развертывания JEE должны были выполняться в дескрипторе развертывания промежуточного модуля App.

Это порождало две проблемы. Во-первых, при повторном развертывании модуля перезаписывались все пользовательские изменения, выполненные в ModuleNameApp, поэтому их часто приходилось перенастраивать. Во-вторых, после выполнения этих изменений модуль App содержал авторские изменения и поэтому должен был контролироваться системой управления исходными кодами. В идеале мы хотим ограничить количество модулей и артефактов, контролируемых системой управления исходными кодами, теми, которые являются абсолютно авторскими.

В WID v6.2 некоторые свойства развертывания можно теперь устанавливать через редактор развертывания модуля, находящийся в первичном SCA-модуле. Редактор развертывания модуля сохраняет изменения в ibm-deploy.scaj2ee в SCA-модуле, который преобразуется в дескриптор развертывания JEE во время развертывания. Хотя редактор развертывания модуля не имеет всех свойств дескриптора развертывания, в большинстве случаев их должно быть достаточно для ваших требований.

Редактор развертывания модуля можно открыть, щелкнув правой кнопкой мыши на имени модуля и выбрав пункт Open Deployment Editor.

Рисунок 3. Редактор развертывания модуля
Рисунок 3. Редактор развертывания модуля

Коллективная разработка при помощи WID и Eclipse

WID-плагины для клиента Subversion

Для взаимодействия с сервером Subversion необходимо установить плагин клиента в среду WID. Существуют два плагина клиента Subversion, которые можно использовать в WID: Subclipse и Subversive. Хотя оба плагина имеют похожий набор функциональных возможностей, Subversive называют официальным стратегическим направлением Eclipse; поэтому для рассматриваемых в данном документе сценариев мы используем плагин Subversive.

Плагин клиента Subversion не включен по умолчанию в список плагинов Eclipse или WID, поэтому его необходимо установить. После установки плагина мы сможем взаимодействовать с репозиторием Subversion из WID.

Некоторая информация о конфигурации плагина клиента Subversion приведена в "Приложении".

Перспективы и представления в WID

В WID и Eclipse имеется несколько перспектив (perspective) и представлений (view), полезных для коллективной разработки. Самыми важными являются следующие четыре:

  • Business Integration (бизнес-интеграция).
  • Resource (ресурс).
  • Team Synchronizing (коллективная синхронизация).
  • SVN Repository Exploring (исследование SVN-репозитория). Отметим, что при использовании системы, отличной от Subversion, название данной перспективы может быть другим.
Рисунок 4. Перспективы, используемые для коллективной разработки в WID
Рисунок 4. Перспективы, используемые для коллективной разработки в WID

Перспектива Business Integration

Перспектива Business Integration является неотъемлемой частью WID, поскольку в ней происходит проектирование артефактов, разработка и интеграция компонентов. Кроме того, в этом представлении можно осуществлять большинство действий коллективной разработки (извлечение (check out), фиксация (commit), обновление).

Представление Physical Resources
Как часть перспективы Business Integration, представление Physical Resources перечисляет имеющие к ней отношение артефакты и ресурсы для библиотек и модулей WID. Представление Physical Resources аналогично представлению Project Explorer перспективы Resource, за исключением того, что показываются только SCA-модули – промежуточные модули не показываются.

Представление Business Integration содержит параметр Show Files (уже не имеющий большого значения в v6.2), отображающий все авторские файлы для артефакта. Например, BPEL-процесс сохраняет логику работы процесса в файле .bpel, но существуют и другие вспомогательные файлы (.bpelex, .mon и Artifacts.wsdl), необходимые для корректного создания BPEL-процесса. Параметр Show Files выделит все четыре файла.

Используйте параметр Show Files следующим образом:

  1. В представлении Business Integration щелкните правой кнопкой мыши на артефакте и выберите Show Files.
Рисунок 5. Show Files
Рисунок 5. Show Files
  1. Некоторые артефакты, например BPEL-процессы, имеют несколько вспомогательных файлов. При включении опции Show Files вы увидите следующее окно. Фильтр Artifact Secondary Files отображает только основной артефакт. При нажатии кнопки Yes этот фильтр будет отключен, и будут выделены все вспомогательные файлы.
Рисунок 6. Отключение фильтра
Рисунок 6. Отключение фильтра
  1. Отметим, что эти файлы выделяются в представлении Physical Resources.
Рисунок 7. Ресурсы HelloWorldProcess
Рисунок 7. Ресурсы HelloWorldProcess

Перспектива Resource

Представление Project Explorer, перечисленное в перспективе Resource, поставляется с Eclipse и выводит список всех модулей и артефактов в рабочей области, включая все промежуточные модули.

Перспектива Team Synchronizing

Представление Synchronize в перспективе Team Synchronizing позволяет синхронизировать рабочую область с удаленным репозиторием. В нем отобразятся все исходящие и входящие изменения и могут быть идентифицированы все конфликты слияния.

Перспектива SVN Repository Exploring

Перспектива SVN Repository Exploring содержит список всех модулей или проектов, которые контролируются системой Subversion. При использовании другого SCM-провайдера может существовать аналогичная перспектива.

Проекты в перспективе SVN Repository Exploring перечисляются по их самому последнему номеру версии, но модули более старых версий тоже можно увидеть и загрузить из системы управления исходными кодами. Ветвления или теги, определенные для конкретного модуля, также можно загрузить через представление SVN Repositories. Можно также использовать представление History для просмотра последовательности изменений модуля.

Представление SVN Repositories
Это главное представление в перспективе SVN Repository Exploring. По умолчанию отображается древовидный список HEAD-версий, содержащий все применяемые модули с соответствующими им стволом (trunk), ветвями (branches) и тегами, перечисленными в репозитории.

Представление SVN Repository Browser
Аналогично представлению SVN Repositories, данное представление отображает последнее время изменения, владельца артефакта и размер файла.

Представление History
Представление History отображает всю хронологию версий и журнал изменений для данного модуля или артефакта. Это представление аналогично SVN Repository Browser, за исключением того, что артефакты группируются по номеру версии, а не по имени модуля.

Коллективная разработка с применением модулей и компонентов-посредников WESB

При создании потока компонентов-посредников (mediation flow) в WID v6.2 его можно оптимизировать для коллективной разработки. По умолчанию этот поток сохраняется как один файл .medflow для всех операций. Таким образом, при наличии в потоке пяти операций вся логика будет находиться в одном файле .medflow.

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

Рисунок 8. Опции потока компонентов-посредников для коллективной разработки
Рисунок 8. Опции потока компонентов-посредников для коллективной разработки

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

  • Отображения операций потока компонентов-посредников должны находиться в одном и том же модуле независимо от того, включена коллективная разработка или нет. Не создавайте отдельный модуль для каждого потока операций.
  • Все пользователи должны загружать модуль из системы управления исходными кодами. Поскольку каждая операция имеет свой собственный файл .medflow, конфликты слияния для логики потока компонентов-посредников возникнуть не могут. Однако они могут возникать, если несколько пользователей изменяют артефакты не посреднического потока.

Общие рекомендации при работе в среде коллективной разработки

Управление SCA-модулями, библиотеками и промежуточными модулями

  • Функциональность коллективной разработки в WID v6.2 значительно усовершенствована. Фактически все взаимодействие с SCM-сервером может осуществляться в перспективе Business Integration. Парадигма "унаследованные против неунаследованных" также существенно упростилась. Все артефакты в модуле сервиса теперь являются авторскими (не унаследованными), тогда как все сгенерированные артефакты и Java-классы (например, файлы, созданные из BPEL-приложения) генерируются во время развертывания или установки приложения.
  • При использовании библиотек помните, что изменение общих BO или WSDL может оказывать неожиданные побочные воздействия на другие модули или компоненты, которые используют ту же библиотеку.
  • Промежуточныемодули создаются компоновщиками WID во время развертывания и обычно не должны контролироваться в системе управления исходными кодами.
  • В редких случаях, когда в редакторе развертывания модуля отсутствует функциональность, присутствующая в дескрипторе развертывания JEE ModuleNameApp, может понадобиться контроль промежуточного модуля ModuleNameApp в системе управления исходными кодами.
  • Контроль промежуточного модуля ModuleNameWeb в системе управления исходными кодами также может понадобиться, если модуль содержит специализированный код, например, клиентские web-интерфейсы. При добавлении специализированного web-содержимого подумайте о создании отдельного Web-проекта для динамичного web-содержимого. В противном случае сгенерированный модуль ModuleNameWeb необходимо будет контролировать в системе управления исходными кодами.

Свойство происхождения артефакта

  • Никогда явно не меняйте флажок происхождения в свойствах артефакта. В отличие от v6.0.2, свойства происхождения в v6.2 более прозрачны и не должны изменяться пользователем. Фактически, если неунаследованный (т.е. авторский) WID-артефакт сделать унаследованным, WID навсегда удалит файл из SCA-модуля. Это происходит из-за того, что компоновщики WID v6.2 считают унаследованный файл сгенерированным. С точки зрения WID сгенерированные файлы могут создаваться только во время развертывания или установки. Следовательно, WID полагает, что унаследованный артефакт присутствует по ошибке, и удаляет его из рабочей области. Отметим, что такое поведение имеет место только для SCA-модулей. Другие модули, например Web или Java-проекты, могут содержать унаследованные артефакты, которые не будут удаляться во время развертывания.
  • Параметр Show Files в представлении Business Integration можно использовать для просмотра списка вспомогательных файлов для данного компонента.

Извлечение модулей из системы управления исходными кодами

  • При работе с модулем, контролируемым в SCM, извлекайте модуль из удаленного репозитория полностью. Никогда не загружайте отдельный артефакт, например один WSDL- или XSD-файл, из модуля, контролируемого в системе управления исходными кодами.
  • Хотя модуль может быть извлечен несколькими пользователями одновременно, только один человек должен иметь доступ по записи в каждый момент времени. Следование этому правилу поможет предотвратить трудно устраняемые конфликты слияния. При необходимости изменить модуль и предотвратить внесение каких-либо изменений другими пользователями используйте блокирование модуля для исключающего доступа по записи.

Синхронизация с удаленным репозиторием

  • Всегда синхронизируйте изменения с репозиторием до выполнения каких-либо фиксаций или обновлений. Хотя полная синхронизация перед фиксацией изменений или обновлением артефактов не является строгим требованием, это правило не только обеспечит вас полным списком изменений, но и поможет предотвратить непреднамеренную перезапись измененных артефактов, сохраненных другими пользователями.
  • При возникновении конфликтов синхронизации разработчикам следует вручную выполнить слияние изменений вместо использования методик слияния текстов при помощи инструментальных средств WID. Хотя эти методики хорошо работают с Java-кодом, они не так эффективны для основанных на XML WID-артефактов. При использовании для объединения двух BPEL-процессов инструментальных средств слияния вы будете работать с "сырым" XML-кодом или обычным текстом (plain text), что противоречит подходу стандартных GUI-редакторов, имеющихся для многих WID-артефактов.
  • Когда артефакт удаляется из локальной рабочей копии и модуль отправляется в репозиторий, он также удаляется и из HEAD-версии. Однако в зависимости от функциональных возможностей SCM артефакт может остаться в репозитории в наборе предыдущей версии.

Контроль версий модуля

  • Версии модуля контролируются только при развертывании через serviceDeploy. Для модулей с назначенной версией, экспортированных как EAR-файлы через WID или добавленных в UTE через Add/Remove Projects, свойства версии не отслеживаются.
  • Рассмотрите вариант управления исходной версией модуля (т.е. 1.0.0) как ствола в системе управления исходными кодами. Все последующие версии должны помещаться в свои собственные ветви корневого ствола.
  • WID в настоящее время не принуждает следовать схеме инкрементного увеличения номера версии модуля. Назначение номеров версий совершенно произвольно и предоставлено пользователю. Это означает, что теоретически вы можете иметь модуль 5.2.5, содержащий более старое содержимое, чем модуль 1.0.0.
  • При фиксации версий модулей как ветвей указывайте номер версии модуля в имени ветви. Также добавляйте соответствующие комментарии, идентифицирующие номер версии. Такое предоставление информации о версии поможет другим пользователям при извлечении модуля из репозитория.
  • Не злоупотребляйте номерами версий модуля. В идеальном случае каждая версия модуля должна выполнять определенную цель – например, модуль, обрабатывающий трафик во время сезонных операций. Ведение версий модуля не должно заменять систему версий SCM и хронологию версий. Предоставьте системе управления исходными кодами обрабатывать ежедневные изменения при разработке.

Коллективная разработка при помощи Subversion

Настройки Subversive

Настройки можно просмотреть и изменить в Window > Preferences > Team > SVN. Для примеров, рассматриваемых в данной статье, мы использовали параметры Subversive по умолчанию; они должны подойти большинству пользователей. Дополнительная информация о настройках и параметрах приведена в документации по Subversive.

Рисунок 9. Настройки плагина клиента Subversive
Рисунок 9. Настройки плагина клиента Subversive

Хотя некоторые настройки можно изменить, всегда оставляйте настройку по умолчанию – использование для имени проекта файла .project а не имени папки. WID-модули используют имя, определенное в файле .project, которое используется также sca.module, sca.modulex и другими артефактами в модуле. При чтении имени модуля из файла метаданных .project, а не из определенной пользователем папки, можно избежать расхождений в имени модуля. Эта настройка находится в Preferences > Team > SVN > Repository.

Рисунок 10. Настройка файла .project Subversion
Рисунок 10. Настройка файла .project Subversion

Структура и схема проекта Subversion

Проекты в Subversion размещаются в репозитории в виде иерархического дерева. Существует несколько способов организации модулей в Subversion, зависящих от требований проекта и сложности решения. Для примеров, представленных в данной статье, мы выбрали размещение каждого модуля или библиотеки в корневом каталоге; при этом не существует правильного или неправильного способа организации модулей в репозитории Subversion. Для небольших проектов, возможно, будет лучше поместить все модули и версии в одну папку, тогда как для сложных корпоративных решений может понадобиться несколько месторасположений репозитория. В любом случае структура схемы проекта в репозитории должна быть единообразной.

Ствол, ветви и теги

Внутри управляемого модуля у вас будет иметься ствол для хранения основной или активной версии модуля, а также необязательные ветви и теги. Когда модуль с самого начала управляется в SCM, артефакты размещаются на стволе. Каждый WID-модуль или библиотека, управляемые в репозитории, содержит свой собственный ствол.

Возможно, понадобится сделать копию ствола, чтобы поддерживать отдельное дерево разработки. Здесь пригодятся ветви. Ветви содержат независимый путь разработки (development path) для данного модуля и часто используются, когда нужно поддерживать несколько потоков разработки модуля. Хотя артефакты ветвей могут трансформироваться во что-то функционально отличное от ствола, ветви всегда начинаются как копия ствола или другой ветви. Например, можно создать ветвь, содержащую логику процесса для обработки транзакций в период праздничных покупок, возможно, предлагая специальные скидки или стимулы для покупок. Аналогично, ветвление часто полезно в WID при реализации нескольких версий модуля. Однако ветви следует создавать только тогда, когда имеется отдельное направление разработки; ветвление не следует использовать как замену хронологии версий для данного модуля.

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

Тегирование и ветвление

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

Можно подумать, что теги очень похожи на ветви. Фактически, если бы вы использовали для создания тегов командную строку Subversion, вы бы не заметили разницы в способе создания тега или ветви – в своей основе они одинаковы. Другими словами, между тегами и ветвями нет технических различий – они просто классифицируются по-разному исходя из их предназначения. Если пользователи не фиксируют изменения в снимке состояния, он будет оставаться тегом. Однако если изменения фиксируются, тег становится ветвью.

Номера версий репозитория

При фиксации модуля или артефакта в репозитории модулю и его артефактам присваивается номер версии, и каждый номер версии представляет хронологический снимок состояния артефакта. По умолчанию в представлении репозитория будет отображаться самая свежая версия (HEAD-версия); однако предыдущие версии можно просмотреть при помощи перспективы SVN Repository Exploring.

Рисунок 11. Номера версий для управляемых артефактов в репозитории
Рисунок 11. Номера версий для управляемых артефактов в репозитории

Добавление WID-проектов в Subversion

Проекты можно добавить в удаленный репозиторий в представлении Business Integration. Хотя рассматриваемая здесь процедура предназначена для Subversion, аналогичные концепции применимы и для других систем управления версиями, например CVS или Clearcase. Добавленные в Subversion проекты будут появляться в HEAD-версии в репозитории.

Для добавления локального проекта в систему управления исходными кодами выполните следующие действия:

  1. В представлении Business Integration щелкните правой кнопкой мыши на имени модуля и выберите Team > Share Project....
Рисунок 12. Share project
Рисунок 12. Share project
  1. Выберите тип репозитория (в данном случае мы используем Subversion). Нажмите кнопку Next.
Рисунок 13. Share project – SVN
Рисунок 13. Share project – SVN
  1. Создайте или выберите репозиторий, в котором должен контролироваться модуль.
    • Если в вашей текущей рабочей области нет других проектов, контролируемых Subversion, необходимо выбрать Create a new repository location (создать месторасположение нового репозитория). Введите URL-адрес репозитория и полномочия для аутентификации. Флажок Enable Structure Detection на вкладке Advanced должен быть установлен с настройками, показанными на рисунке 14.
    • В противном случае выберите Use existing repository location (использовать месторасположение существующего репозитория). Нажмите кнопку Next.
Рисунок 14. Enable Structure Detection
Рисунок 14. Enable Structure Detection
Рисунок 15. Use existing repository location
Рисунок 15. Use existing repository location
  1. Укажите схему и месторасположение проекта. Отметим, что все это совершенно субъективно – никакого правильного или неправильного способа организации ваших модулей в системе управления исходными кодами не существует, и у вас может быть свой собственный способ организации, более простой или более сложный. Мы рекомендуем следующую конфигурацию:
    • Выберите Advanced Mode.
    • Оставьте поле Name on Repository в значении Use project name.
    • Измените поле Project Repository Layout на Use single project layout.
    • Оставьте отмеченным флажок Use Subversion recommended layout (trunk, branches, tags) – использовать рекомендованную в Subversion схему (ствол, ветви, теги). Ваши настройки должны быть аналогичны изображенным на рисунке 16.
    • Нажмите кнопку Next.
Рисунок 16. Указание месторасположения
Рисунок 16. Указание месторасположения
  1. Введите необязательное описание в поле comment. Будет создаваться стандартный комментарий по умолчанию, но вы можете изменить его на что-то более конкретное. Оставьте отмеченным флажок Launch the Commit Dialog for the shared resources (запускать окно подтверждения для общих ресурсов).
Рисунок 17. Флажок Launch the Commit Dialog for the shared resources
Рисунок 17. Флажок Launch the Commit Dialog for the shared resources
  1. Нажмите кнопку Finish для фиксации изменений модуля в репозитории.
  2. Отобразится новое диалоговое окно для ввода комментария. Он отличается от предыдущего комментария, поскольку применяется к артефакту, а не к модулю. Введите текст и нажмите кнопку OK.
  3. Теперь модуль контролируется в системе управления исходными кодами. Обратите внимание на то, что теперь рядом с именем модуля в представлении Business Integration присутствует номер версии и URI.
Рисунок 18. Новый URI
Рисунок 18. Новый URI

Управление интеграционными решениями в системе управления исходными кодами

В WID v6.2 появились т.н. интеграционные решения (integration solutions). Это неразвертываемые проекты, позволяющие логически ссылаться на взаимодействующие модули в рабочей области, включая SCA-модули, модули-посредники, библиотеки и Java-проекты. Схема интеграционного решения показывает вызовы и взаимоотношения между модулями.

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

Для добавления проектов в интеграционное решение:

  1. Щелкните правой кнопкой мыши на Project References и выберите Add or Remove Project References (добавить или удалить ссылки на проект).
Рисунок 19. Add or Remove Project References
Рисунок 19. Add or Remove Project References
  1. Отображается окно, содержащее список проектов в рабочей области. Отметьте (или снимите отметку) модули, которые должны управляться в репозитории. Нажмите кнопку OK для сохранения изменений.
Рисунок 20. Выбор проектов
Рисунок 20. Выбор проектов

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

  1. Щелкните правой кнопкой мыши на Project References и выберите Check Out Referenced Shared Projects (загрузить упоминаемые общие проекты).
Рисунок 21. Check Out Referenced Shared Projects
Рисунок 21. Check Out Referenced Shared Projects
  1. Проекты загружаются из удаленного репозитория; при этом все модули, существующие в рабочей области, будут перезаписаны.

В большинстве случаев лучше всего загружать упоминаемые модули непосредственно из репозитория, а не использовать функциональность интеграционного решения. При использовании интеграционного решения для загрузки модуля из репозитория загружается только ствол из HEAD-версии. Более того, интеграционные решения могут контролироваться в SCM так же, как и любой другой WID-модуль. По своей сути интеграционные решения очень просты и состоят только из projectSet.psf и solution.graphml, которые идентифицируют зависимости модулей решения.

Загрузка проектов из Subversion

Загрузить модули из Subversion можно путем выполнения следующих действий:

  1. Откройте перспективу SVN Repository Exploring. При необходимости добавьте New Repository Location (месторасположение нового репозитория) в рабочую область.
Рисунок 22. New Repository Location
Рисунок 22. New Repository Location
  1. Обновите месторасположение репозитория для просмотра самого последнего снимка состояния в репозитории.
Рисунок 23. Обновление месторасположения репозитория
Рисунок 23. Обновление месторасположения репозитория
  1. Разверните модуль или проект, который нужно загрузить. При использовании схемы ствол/ветви/теги, рассмотренной ранее, разверните также соответствующую папку. В данном случае мы будем загружать копию ствола.
Рисунок 24. Копия ствола
Рисунок 24. Копия ствола
  1. Щелкните правой кнопкой мыши на папке trunk и выберите Check Out для импорта модуля в локальную рабочую область.
Рисунок 25. Check out
Рисунок 25. Check out

Удаление проектов и артефактов

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

Синхронизация различий между рабочей копией и репозиторием

При работе с модулями, контролируемыми в системе управления исходными кодами, между локальной и удаленной копиями модулей могут появляться различия. Чтобы сохранить соответствие артефактов в локальной рабочей копии и удаленном репозитории, локальную рабочую область необходимо синхронизировать с удаленным репозиторием. Синхронизация локальной и удаленной копий, а также идентификация артефактов, которые нужно зафиксировать или обновить, осуществляется в перспективе Team Synchronizing. Если артефакт изменялся и фиксировался несколькими пользователями, в мастере синхронизации появится предупреждение о конфликте слияния.

Для синхронизации модуля рабочей области с удаленным репозиторием выполните следующие действия:

  1. В представлении Business Integration щелкните правой кнопкой мыши на имени модуля и выберите Team > Synchronize with Repository.
Рисунок 26. Synchronize with Repository
Рисунок 26. Synchronize with Repository
  1. Появится диалоговое окно, уведомляющее о том, что будет открыта перспектива Team Synchronizing. Нажмите кнопку Yes.
Рисунок 27. Перспектива Team Synchronizing
Рисунок 27. Перспектива Team Synchronizing
  1. В представлении Synchronize отобразится список измененных артефактов. Обратите внимание на то, что в данном случае имеются артефакты с исходящими изменениями, входящими изменениями и конфликтами.
Рисунок 28. SourceControlTest
Рисунок 28. SourceControlTest
  1. По умолчанию выбран вариант Incoming/Outgoing Mode. Это означает, что все изменения и конфликты будут появляться в списке синхронизации. Как показано ниже, можно изменить фильтр для отображения только исходящих изменений, входящих изменений или конфликтов.
Рисунок 29. Фильтрация изменений
Рисунок 29. Фильтрация изменений

В нижней части окна WID отображается количество входящих, исходящих и конфликтных изменений.

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

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

Фиксация изменений в репозитории

Все изменения, сделанные в локальной рабочей копии, должны быть сохранены в удаленном репозитории до вступления этих изменений в силу. Здесь вступает в действие процесс фиксации изменений (commit). При добавлении проекта в репозиторий процесс первоначальной фиксации сохраняет все артефакты из локальной рабочей копии в репозиторий.

Артефакты необходимо фиксировать в репозитории при следующих обстоятельствах:

  • Изменения в артефактах, существующих в репозитории, т.е. существующий BO изменяется для включения новых полей данных.
  • Добавление новых артефактов в модуль, существующий в репозитории, т.е. новый BPEL-процесс добавляется в локальную рабочую копию.
  • Удаление артефактов из модуля, т.е. WSDL-файл удаляется из рабочей копии.

Флажок "грязный" (>) в рабочей области уведомляет, что ваша локальная копия отличается от копии в удаленном репозитории. Возможно, вы захотите синхронизировать или зафиксировать изменения в репозитории для гарантирования согласованности удаленной копии с вашей локальной рабочей копией.

Рисунок 31. Флажок уведомляет о наличии изменений в рабочей области
Рисунок 31. Флажок уведомляет о наличии изменений в рабочей области

Фиксация изменений в рабочей области выполняется следующим образом:

  1. Синхронизируйте рабочую область с удаленным репозиторием. Если между локальной рабочей копией и удаленным репозиторием различия отсутствуют, фиксировать или обновлять нечего.
  2. Откройте перспективу Team Synchronizing для просмотра сводной информации о синхронизации.
  3. Зафиксируйте изменения в репозитории. Можно зафиксировать либо все изменения в модуле сразу, либо фиксировать отдельные артефакты. Щелкните правой кнопкой мыши на имени модуля или артефакта и выберите Commit.... Отобразится диалоговое окно Commit.
Рисунок 32. Диалоговое окно Commit
Рисунок 32. Диалоговое окно Commit

В качестве альтернативного способа можно нажать кнопку Commit All Outgoing Changes (зафиксировать все исходящие изменения), расположенную в верхней части окна Synchronize.

Рисунок 33. Кнопка Commit All Outgoing Changes
Рисунок 33. Кнопка Commit All Outgoing Changes
  1. Введите необязательный комментарий в диалоговое окно Commit. Нажмите кнопку OK для фиксации изменений.
Рисунок 34. Ввод комментария
Рисунок 34. Ввод комментария
  1. После фиксации изменений модуля и синхронизации рабочей области обратите внимание на отсутствие открытых изменений для данного модуля.
Рисунок 35. Изменения для модуля отсутствуют
Рисунок 35. Изменения для модуля отсутствуют

Примечания.

  • Выполняйте синхронизацию часто для проверки обновлений, выполненных другими пользователями. Это особенно важно для базовых артефактов, которые могут использоваться в нескольких модулях, например библиотеки с WSDL и XSD.
  • При попытке зафиксировать изменения элементов, измененных другими пользователями, отобразится предупреждение о конфликте слияния. Хотя в перспективе Team Synchronizing имеются инструментальные средства слияния (merge), они разработаны для традиционного кода, например, на Java, и недостаточно хорошо работают для основанных на XML WID-артефактов. Поэтому конфликты слияния следует обрабатывать вручную.
  • Операция фиксации изменений может использоваться только для модулей, которые уже контролируются системой управления исходными кодами. При создании нового модуля используйте диалоговое окно Share Project....
  • При любом изменении локальной рабочей копии рядом с именем модуля появляется маркер "грязный" (>).

Обновление изменений из репозитория в локальной рабочей копии

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

Обновление локальной рабочей копии выполняется следующим образом:

  1. Синхронизируйте рабочую область с удаленным репозиторием. Если все синхронизировано, обновления не нужны.
  2. Просмотрите список синхронизации в перспективе Team Synchronizing.
  3. Обновите локальную рабочую область. Аналогично операции фиксации изменений можно обновить либо модуль полностью, либо отдельные артефакты. Щелкните правой кнопкой мыши на имени модуля или имени артефакта и выберите Update....
Рисунок 36. Обновление модуля
Рисунок 36. Обновление модуля

Также можно использовать кнопку Update All Incoming Changes (обновить все входящие изменения) непосредственно в представлении Synchronize.

Рисунок 37. Update All Incoming Changes
Рисунок 37. Update All Incoming Changes
  1. Теперь рабочая область находится в актуальном состоянии.

Управление конфликтами

Предположим, что два пользователя, Джо и Том, работают над одним и тем же WID-проектом. Они оба загрузили набор модулей из репозитория и без уведомления друг друга о своих планах выполнили ряд изменений BPEL-процесса в модуле ShipOrderModule. Джо сделал свои изменения быстро и синхронизировал свою копию в удаленном репозитории. Конфликтов нет, поэтому он зафиксировал изменения и закрыл свою рабочую область. Спустя пару часов Том решает зафиксировать свои изменения в процессе. Он выполняет синхронизацию и сразу же обнаруживает конфликт – Джо тоже работал с тем же набором артефактов.

В данный момент у Тома есть три варианта:

  1. Он может принудительно отправить свои изменения в HEAD репозитория, перезаписав, таким образом, изменения Джо (артефакты Джо все равно будут существовать в предыдущей версии, так как они уже были зафиксированы).
  2. Он может обновить свою локальную рабочую копию, чтобы она отражала изменения, выполненные Джо в репозитории, но он потеряет всю свою недавнюю работу.
  3. Он может использовать средства слияния для объединения различий между копией Джо и своей собственной работой.

При слиянии конфликтов есть несколько вариантов работы. Для традиционного исходного кода, например Java, наилучшим и простейшим вариантом является использование инструментальных средств слияния, помогающих интегрировать обе версии кода. Однако это не совсем удобно для WID-артефактов, поскольку они основаны на XML и обычно с трудом интегрируются в формате простого текста (raw-text). Чаще всего WID-артефакты разрабатываются при помощи GUI-средств, поэтому выполнение текстовой интеграции – весьма рискованное и подверженное ошибкам мероприятие. В настоящее время нет способа выполнить слияние и сравнение WID-артефактов графическим способом.

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

Конфликты слияния говорят о важности частой синхронизации. Если бы Том регулярно выполнял синхронизацию, а не ждал несколько часов, он бы заметил выполненное Джо изменение BPEL-процесса задолго до своих изменений. Он мог бы тогда обсудить изменения с Джо и, возможно, интегрировать их в свою локальную рабочую копию с целью предотвращения неопределенности во время фиксации собственных изменений.

Итак, какой же подход является наилучшим? По мере возможности попытайтесь вовсе избегать появления конфликтов слияния. Если известно, что несколько пользователей будут работать с общим модулем или библиотекой, обсудите это в коллективе и договоритесь, что только один человек будет изменять артефакт в определенный промежуток времени. Можно также использовать варианты Lock и Unlock в меню Team для блокировки доступа по чтению или записи к определенным модулям или артефактам.

Параметр Mark as Merged

Представление Synchronize содержит параметр Mark as Merged (отметить как объединенный), позволяющий переопределять маркеры конфликтов, отмечая артефакт так, как будто он уже был объединен. Это полезно при ручном слиянии рассматриваемого артефакта и нежелании использовать текстовые инструментальные средства сравнения и слияния для объединения конфликтов.

Для отметки файла как объединенного щелкните правой кнопкой мыши на модуле или артефакте в представлении Synchronize и выберите Mark as Merged. Индикатор конфликта слияния будет удален, и артефакт можно будет обновить или зафиксировать.

Блокировка и разблокировка ресурсов

Чтобы избежать конфликтов слияния, можно запретить нескольким пользователям доступ по записи к модулю или ресурсу. Это можно сделать путем установки блокировок для конкретного модуля. Если модуль или артефакт блокирован, другие пользователи по-прежнему могут загружать модуль из репозитория, но они не смогут фиксировать какие-либо изменения до снятия блокировки.

Блокировка модуля осуществляется следующим образом:

  1. Загрузите модули из репозитория.
  2. В представлении Business Integration щелкните правой кнопкой мыши на модуле и выберите Team > Lock....
Рисунок 38. Блокировка модуля
Рисунок 38. Блокировка модуля
  1. Введите необязательный комментарий и отметьте флажок Lock recursively (рекурсивная блокировка). Нажмите кнопку OK.
Рисунок 39. Рекурсивная блокировка
Рисунок 39. Рекурсивная блокировка
  1. Теперь модуль может использоваться только вами. В рабочей области появится розовая пиктограмма замка.
Рисунок 40. Заблокированные модули
Рисунок 40. Заблокированные модули
  1. Если исключающий доступ вам больше не нужен, обязательно разблокируйте модуль.
    • Щелкните правой кнопкой мыши на имени корневого модуля и выберите Team > Unlock.
    • Отметьте флажок Recursively и нажмите кнопку Yes. Теперь модуль должен быть разблокирован в вашей рабочей области.
Рисунок 41. Разблокировка модуля
Рисунок 41. Разблокировка модуля
Рисунок 42. Установка флажка Recursively
Рисунок 42. Установка флажка Recursively

Примечания.

  • Блокировка влияет только на доступ к артефакту по записи. Если модуль блокируется одним пользователем, остальные пользователи все равно могут загружать этот модуль, но не могут зафиксировать какие-либо изменения до снятия блокировки.
  • Несколько пользователей могут получить доступ по записи к заблокированному модулю при помощи флажка Force lock. Однако так делать не рекомендуется, поскольку возникает возможность появления конфликтов слияния.
Рисунок 43. Флажок Force lock
Рисунок 43. Флажок Force lock

Работа с ветвями

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


Создание новой ветви из представления Business Integration

Создать ветвь из существующего модуля можно в представлении Business Integration. Для этого модуль должен находиться в Subversion (либо как ствол, либо как другая ветвь) и быть загруженным в локальную рабочую копию.

  1. Убедитесь, что ваша локальная рабочая область содержит ствол или ветвь для модуля, из которой нужно создать ветвь.
  2. Щелкните правой кнопкой мыши на имени модуля и выберите Team > Branch.... Появится новое окно.
  3. Введите имя для этой ветви и отметьте флажок Start working in the branch (начать работать в ветви). Также настоятельно рекомендуется вводить комментарий, поскольку он позволит вашим коллегам понять назначение ветви. Нажмите кнопку OK.
Рисунок 44. Ввод месторасположения ветви
Рисунок 44. Ввод месторасположения ветви
  1. Ветвь будет создана в удаленном репозитории.
Рисунок 45. Ветвь, созданная в удаленном репозитории
Рисунок 45. Ветвь, созданная в удаленном репозитории

При выборе флажка Start working in the branch ваша локальная рабочая копия будет отражать имя новой созданной ветви.

Рисунок 46. Каталог новой ветви
Рисунок 46. Каталог новой ветви

Можно также создавать ветви непосредственно в Subversion из представления SVN Repository Exploring.

  1. Откройте представление SVN Repository Exploring и выберите желаемый модуль. В данном случае у нас будет ветвь от ствола HelloWorldProcess. Щелкните правой кнопкой мыши на стволе и выберите New > Branch....
Рисунок 47. Новая ветвь
Рисунок 47. Новая ветвь
  1. Отобразится новое окно. Введите имя ветви и необязательный комментарий. Нажмите кнопку OK.
Рисунок 48. Введите имя ветви и необязательный комментарий
Рисунок 48. Введите имя ветви и необязательный комментарий
  1. Ветвь появится в представлении SVN Repositories, но ее необходимо загрузить, чтобы она появилась в локальной рабочей копии.
Рисунок 49. Список ветвей
Рисунок 49. Список ветвей

Загрузка ветви из репозитория

  1. Найдите в представлении SVN Repositories модуль и ветвь, которую вы хотели бы загрузить. Разверните элемент branches, чтобы получить список доступных ветвей для модуля. В данном примере мы будем загружать ветвь branch03.
  2. Щелкните правой кнопкой мыши на имени ветви и выберите Check Out.
Рисунок 50. Загрузка ветви
Рисунок 50. Загрузка ветви
  1. Поскольку ствол и все ветви для модуля совместно используют одно и то же имя модуля в репозитории, возможно, появится предупреждение о том, что модуль уже есть в локальной рабочей копии. Выберите имя модуля для перезаписи локальной рабочей области и нажмите кнопку OK.
Рисунок 51. Переопределение проекта
Рисунок 51. Переопределение проекта
  1. Выбранная ветвь теперь появится в локальной рабочей копии.

Расширенные возможности Subversion

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

Операции переопределения

Существуют две команды переопределения, доступные в представлении Synchronize: Override and Commit и Override and Update. Эти команды переопределяют все изменения в репозитории (при их фиксации) или локальной рабочей копии (при обновлении) для данного модуля или артефакта. Использовать команды переопределения нужно с осторожностью – можно непреднамеренно затереть изменения, выполненные в локальной рабочей области или в удаленном репозитории.

Обычно наилучшим вариантом является использование стандартных команд Commit and Update и Mark as Merged.

Щелкните правой кнопкой мыши на модуле или артефакте для доступа к следующим командам переопределения:

Рисунок 52. Операции переопределения commit and update
Рисунок 52. Операции переопределения commit and update

Откат изменений в локальной рабочей копии

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

Для возврата модуля в предыдущее состояние в рабочей области щелкните правой кнопкой мыши на имени модуля и выберите Team > Revert.... Появится всплывающее меню со списком измененных артефактов. Выберите артефакты, которые хотите восстановить и нажмите кнопку OK. Обратите внимание, что флажок "грязный" (>) для этих артефактов удаляется.

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

Использование представления History

Возможно, вы захотите просмотреть хронологию версий конкретного модуля или артефакта в системе управления исходными кодами. Представление History, расположенное в перспективе SVN Repository Exploring, отобразит версию артефакта. В этом представлении отображаются: номер версии, время фиксации изменений, автор артефакта и все доступные комментарии.

Для просмотра хронологии артефакта выполните следующие действия:

  1. Откройте перспективу SVN Repository Exploring.
  2. Разверните модуль и найдите артефакт, для которого хотите просмотреть хронологию версий.
  3. Щелкните правой кнопкой мыши на артефакте и выберите Show History.
Рисунок 54. Отображение хронологии
Рисунок 54. Отображение хронологии
  1. Список доступных версий отобразится в представлении History. Выберите версию для просмотра хронологии изменений.
Рисунок 55. Представление History
Рисунок 55. Представление History

Выбор конкретной версии в репозитории

В большинстве случаев вы будете загружать модули из HEAD-версии, но иногда возникает потребность загрузить конкретную версию. Представление SVN Repositories позволяет просматривать любую версию в репозитории, а также загружать ствол или ветви в локальную рабочую область.

Просмотреть и загрузить конкретную версию модуля можно следующим образом:

  1. Откройте перспективу SVN Repository Exploring и найдите представление SVN Repositories. Найдите древовидный список REVISIONS в корне репозитория.
Рисунок 56. Дерево версий
Рисунок 56. Дерево версий
  1. Щелкните правой кнопкой мыши на REVISIONS и выберите Select Revision....
  2. Появится всплывающее окно. Можно выбрать существующую версию по дате (Date) или номеру версии (Revision number). Нажмите кнопку Browse... для выбора номера версии. После выбора версии нажмите кнопку OK.
Рисунок 57. Выбор версии
Рисунок 57. Выбор версии
  1. Для вывода списка модулей, имеющихся в указанной версии, разверните дерево REVISIONS, пока не появятся ствол, ветви и теги. Теперь можно загрузить версию модуля так же, как это делалось для HEAD-версии.
Рисунок 58. Дерево версий
Рисунок 58. Дерево версий

Переключение из одной версии рабочей области в другую

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

Переключить модуль в другую версию можно следующим образом:

  1. Откройте перспективу Business Integration и выделите модуль, в который хотите переключиться.
  2. Щелкните правой кнопкой мыши на имени модуля и выберите Team > Switch....
  3. Отобразится новое окно.
    • Нажмите на URL Browse... для выбора URL месторасположения модуля. Выберите соответствующий ствол или ветвь.
Рисунок 59. Просмотр
Рисунок 59. Просмотр
  • В разделе Revision выберите версию по дате или номеру. В данном случае мы используем Revision number. Нажмите кнопку Revision Browse... и выберите версию.
  • Оставьте в поле Depth значение копии по умолчанию Working.
  • Ваши настройки должны выглядеть примерно так, как показано на рисунке 60. Нажмите кнопку OK.
Рисунок 60. Просмотр версий
Рисунок 60. Просмотр версий
Рисунок 61. Выбор URL и версии ресурса репозитория
Рисунок 61. Выбор URL и версии ресурса репозитория
  1. Выбранная версия модуля будет импортирована в вашу рабочую область. Обратите внимание, что номер версии изменился в соответствии с вашим выбором.
Рисунок 62. Номер версии
Рисунок 62. Номер версии

Отметим, что команды Select Revision и Switch аналогичны в том, что обе позволяют загружать предыдущую версию из репозитория. Однако Select Revision доступна только в перспективе SVN Repository Exploring, тогда как команда Switch доступна в перспективе Business Integration через меню Team. Если модуль не существует в локальной рабочей копии, следует использовать Select Revision, а команду Switch следует использовать для модулей, которые уже существуют в ней.

Замена локальной рабочей копии версией из SCM

Аналогично переключению можно использовать функциональность Replace With для переключения между доступными ветвями или версиями, существующими в репозитории. Никаких преимуществ этот метод по сравнению с переключением не несет – он просто дает еще один способ выполнения того же действия.

  1. В представлении Business Integration щелкните правой кнопкой мыши на имени модуля и выберите Replace With.
  2. Выберите соответствующий вариант ниже и следуйте за указаниями контекстных меню, как делали при переключении. При выборе Latest from Repository локальная рабочая копия будет замещена модулем последней версии, находящимся в репозитории.
Рисунок 63. Использование Replace With для переключения ветвей
Рисунок 63. Использование Replace With для переключения ветвей

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


Поддержка версий модулей в WID

Поддержка версий модулей является новой возможностью в WID v6.2; она позволяет делать несколько вещей. Во-первых, можно логически управлять модулями на основе определенного набора функциональных возможностей и, если понадобится, легко развертывать конкретную версию для выполнения определенной цели. Вероятно, еще важнее то, что можно одновременно устанавливать несколько версий в одну и ту же исполняющую систему. Управлять версиями модулей можно только через редактор зависимостей в WID.

Для создания EAR-файла с указанием версии модуль, поддерживающий версии, необходимо развертываться с использованием serviceDeploy. Модули, экспортированные как EAR-файлы из WID, будут компоноваться и устанавливаться корректно, но они не будут поддерживать версии. Аналогично, приложения, добавленные в UTE через Add/Remove projects, тоже не поддерживают версии.

Поставляемая IBM схема версий использует трехчастную систему нумерации версий в формате <MAJOR>.<MINOR>.<SERVICE>. Например, ранняя версия модуля может иметь номер 1.0.2. Значения MAJOR, MINOR и SERVICE совершенно субъективны и изменяются пользователем. Разработчик должен сам решать, когда увеличивать каждую из категорий, так как WID не отслеживает инкрементные номера версий. Более того, хотя настоятельно рекомендуется последовательно увеличивать нумерацию, это не обязательное правило. Другими словами, в WID ничто не мешает вам создать версию модуля, скажем, 1.0.1, содержащую более новое содержимое, чем версия 2.1.0. Зависимые проекты и библиотеки версионного модуля не обязаны поддерживать версии и иметь тот же номер версии, что и модуль. Свойства системы поддержки версии модуля можно установить в настройках зависимостей модуля.

Рисунок 64. Настройки системы версий модуля и номер версии
Рисунок 64. Настройки системы версий модуля и номер версии

Помните, что если модуль поддерживает версии, только имя модуля изменяется уникально. Это позволяет установить две и более копии одного и того же приложения в исполняющую систему WPS; однако ни один шаблон BPEL-процесса или пользовательского задания изменен не будет, что может воспрепятствовать установке нескольких версий приложения в одну систему. Шаблоны заданий и процессов должны быть уникальны для данного контейнера заданий или процессов. При попытке одновременной установки нескольких версий модуля в одну и ту же исполняющую систему без ведения версий пользовательского задания или BPEL-процесса установка приложения завершится неудачно. Для решения этой проблемы необходимо либо организовать ведение версий вашего BPEL-процесса во время проектирования, либо выполнить рефакторинг имени шаблона BPEL-процесса.

Поддержка версий модулей по умолчанию отключена, но ее можно включить для любого модуля через Window > Preferences > Business Integration > Module And Library Versions.

Компоновка модуля с поддержкой версий

Существуют два WID-артефакта, связанные с поддержкой версии модулей:

  • sca.module. В этом файле определяется имя SCA-модуля. При использовании модуля с поддержкой версий его имя изменяется во время развертывания (к строке имени модуля добавляется номер версии). Отметим, что это работает только для приложений, развертываемых через serviceDeploy, а не через Add/Remove projects.
  • sca.module.attributes. Создается только при включении поддержки версий модуля. Здесь устанавливается определяемый пользователем номер версии. Напоминаем еще раз: номер версии применяется только при развертывании модуля через serviceDeploy.

Чтобы свойства поддержки версий модуля вступили в действие, модуль должен развертываться через serviceDeploy. Во время развертывания номер версии, определенный в файле sca.module.attributes, применяется для формирования нового имени модуля.

Модуль с поддержкой версий идентифицируется по следующему шаблону:

ModuleName_vX_Y_ZApp.ear

где X, Y и Z – это номера версии major, minor и service.

Например, предположим, что в рабочей области WID имеется модуль HelloWorldProcess. Мы включили поддержку версий и указали версию модуля как 1.0.1. Если модуль развертывается через WID, полученный EAR-файл будет называться HelloWorldProcessApp.ear. Однако при включенной поддержке версий и развертывании через serviceDeploy имя модуля будет HelloWorldProcess_v1_0_1App.ear.

Связь поддержки версий модулей с системой управления исходными кодами

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

Модули с поддержкой версий должны храниться в том же дереве каталогов, что и родительский модуль. Мы рекомендуем сохранять исходную версию модуля (скажем, 1.0.0) в стволе, а последующие версии в ветвях этого ствола.

В качестве альтернативного способа можно в стволе сохранять последнюю или самую стабильную версию, а все предыдущие версии хранить в ветвях. Любой подход будет правильным, если проводить его последовательно. Ради последовательности мы рекомендуем первую версию хранить в стволе, а все последующие хранить как ветви. Если нужно выполнить изменение в базовом артефакте, которое окажет влияние на все версии, его можно развернуть в стволе и делегировать ветвям по мере необходимости. Отметим, что стволы и ветви – это внутренние понятия Subversion; другие SCM-продукты могут использовать другие соглашения.


Приложение 1. Список WID-артефактов, контролируемых в системе управления исходными кодами

Карты бизнес-объектов:

  • .map, .xsl, .xsl.smap

Карты интерфейсов:

  • .ifm, <IFMapName>_ifm.mon

Общие WPS-артефакты:

  • .component, .module, .modulex, .import, .export, .mon, ibm-deploy.scaj2ee

Метаданные Eclipse:

  • .settings folder, MANIFEST.MF, .classpath, .project

Интерфейсы:

  • .wsdl

Типы данных (бизнес-объекты):

  • .xsd

Модули-посредники:

  • .medflow, .mfc, .mfcex

Бизнес-процессы:

  • .bpel, .bpelex, <ProcName>Artifacts.wsdl, <ProcName>_bpel.mon

Машины бизнес-состояний (отметим, что применяемый .bpel-файл для машины состояния теперь генерируется во время установки приложения и, следовательно, не контролируется в SCM):

  • .sacl, .saclex, <BSMName>_sacl.mon

Задания пользователя:

  • .tel, .itel (inline task only), <HTName>_tel.mon

Бизнес-правила:

  • .brg, .brgt, <BRGName>_brg.mon, .ruleset

Селекторы:

  • .sel, .selt, <SelName>_sel.mon

Взаимосвязи:

  • .rel, .rol

Модули интеграционного решения:

  • .project
  • projectSet.psf
  • solution.graphml

Приложение 2. Установка плагина клиента Subversive

Для подключения сервера Subversion к WID или Eclipse необходимо установить соответствующий плагин клиента. Как мы уже упоминали, доступны два плагина, работающих с Subversion – Subclipse и Subversive. Для примеров, рассматриваемых в данном документе, мы использовали Subversive, однако можно также использовать и Subclipse.

Для установки плагина клиента Subversive обратитесь к руководству по установке Subversive: http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/install.php.

Мы не рекомендуем устанавливать оба плагина Subclipse и Subversive в одном экземпляре WID. Поскольку эти плагины имеют похожие системы меню и перспективы SVN Repository Exploring, часто бывает трудно отличить их друг от друга.

Установка и настройка сервера Subversion

Для использования Subversion необходимо установить сервер Subversion. Чаще всего это делает системный администратор. Поскольку основное внимание здесь уделяется клиентскому программированию WID, настройка исполняющей системы Subversion выходит за рамки данной статьи. В данной статье мы использовали дистрибутив Collabnet.

Дополнительная информация по настройке Subversion приведена на отличном и бесплатном ресурсе Управление версиями при помощи Subversion.

Независимо от того, какой плагин клиента и сервер Subversion вы используете, они должны иметь одинаковый уровень версий.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы, WebSphere
ArticleID=767036
ArticleTitle=Коллективная разработка и управление артефактами в WebSphere Integration Developer v6.2
publish-date=10212011