Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘ClearCase’

Дерево версий ClearCase – глюк или фича?

Posted by Шамрай Александр на Январь 5, 2012

Вот такое вот счастье получилось сделать из одной и той же вьюхи.

Posted in ClearCase | Отмечено: , , | Leave a Comment »

Сравнение концепции ClearCase UCM и RTC

Posted by Шамрай Александр на Ноябрь 15, 2010

Оригинал: Comparing concepts between ClearCase UCM and RTC

Введение

Некоторые путаются в сходствах и различиях между Rational ClearCase и Rational Team Concert. В основном это связано с изменениями в терминологии, а в некоторых случаях это связано с различными моделями использования и возможностями продуктов. Данная статья направлена на прояснение некоторых моментов.

Демонстрация будет выполняться на основе UCM, так как многие из наших клиентов используют ClearCase UCM. Если вы используете ClearCase UCM интегрированный с ClearQuest, то настоятельно рекомендуется также прочитать Сравнение концепции ClearQuest и Rational Team Concert.

Базовая терминология

Давайте рассмотрим различия между ClearCase UCM и Rational Team Concert (RTC). ClearCase является системой управления конфигурацией. Клиенты могут использовать его отдельно или с функциональностью UCM. UCM дает пользователям создавать программные Компоненты (Component), а затем создавать Базовые линии (Baseline) на эти компоненты. Файлы для изменения Извлекаются на редактирование (Checked Out), изменяются, а затем Регистрируются (Checked In) в рамках представления, которое является рабочим пространством для разработки. Наборы изменений (Change Sets) составляются из отдельных изменений, внесенных в рамках Активности (Activity). Эти Наборы изменений затем становятся общедоступными для других членов команды через операцию Доставки (Delivery) этих Наборов изменений. ClearCase хранит эти артефакты в собственном формате и сохраняет все свои данные в репозитории, который называется VOB. Каждый VOB может содержать один или более компонентов UCM. Каждый VOB может хранить артефакты в любой структуре каталогов, которую пользователь хочет использовать. ClearCase поддерживает параллельную разработку и, когда возникают конфликты между версиями одного и того же файла, то они разрешаются с помощью операции Слияния (Merge). В базовом ClearCase, VOB-файлы могут содержать Ветви (Branch), которые обеспечивают логическое «разделение» кода для параллельной разработки, которая выполняется изолированно. В UCM эти Ветви имеют некоторые формальные ограничения и называются UCM-потоки (UCM Streams). Участник команды разработки выполняет Доставку его или ее изменений из их рабочего пространства, называемого Представлением (View), в Поток (Stream). Другие члены команды будут выполнять Обновление (Rebase) их Потока и забирать изменения, которые доставлены в родительский Поток.

ClearCase есть такое понятие как Динамическое представление (Dynamic View), это рабочее пространство, которое обновляется без вмешательства пользователя, на основе пользовательских настроек. ClearCase есть также концепция Статических представлений (Snapshot View), которое является копией рабочего пространства, ассоциированного с состоянием репозитория в определенный момент времени. Статическое представление приводится к «текущему состоянию»с помощью операции Обновить (Updating) представление. В любом из этих типов представлений, Базовые линии и Наборы изменений могут быть доставлены из потока в поток, при этом любые необходимые операции Слияния по отдельным файлам будут обнаружены системой, а затем их должен будет разрешить пользователь. Также как Компоненты получают Наборы изменений, применяемые к ним, отдельные Компоненты могут иметь Базовые линии (в основном как метка для всех артефактов в рамках Компонента или VOB), применяемые к ним. «Основная базовая линия» с набором базовых линий нескольких Компонентов называется Композитная базовая линия (Composite Baseline).

В RTC SCM есть многие из этих же понятий, но есть некоторые незначительные отличия. Jazz имеет единое хранилище, в котором хранятся его артефакты как REST ресурсы. Эти ресурсы хранятся в базе данных. Jazz поддерживает использование многих баз данных, включая Oracle, DB2 и SQL Server. Это, в общем, используется как Jazz Репозиторий (Jazz Repository). В Jazz разрабатываемая программа разбивается на программные Компоненты (Component). Эти Компоненты могут содержать артефакты в любой структуре каталогов, и параллельная разработка поддерживается с использованием Jazz Потоков (Jazz Streams). Пользователи, работающие с Jazz Компонентой, присоединяются к проекту и создают своё собственное Рабочее пространство Репозитория (Repository Workspace) (которое содержит копии всех их Наборов изменений (Change Set)), а также Личное Рабочее пространство (Sandbox) на своем локальном компьютере. Все изменения файлов отслеживаются клиентом Jazz, и пользователь в дальнейшем будет Регистрировать (Check In) свои изменения. В Jazz нет понятия изъять на редактирование, но Jazz поддерживает Блокировку (Locking) ресурсов. Когда пользователь видит изменения в своем Личном рабочем пространстве, он будет Регистрировать изменения и связывать их с Набором изменений, который собирает отдельные изменения и сохраняет их в Рабочем пространстве Репозитория. Эти Наборы изменений могут быть Доставлены (Deliver) в один или несколько Потоков Jazz. Другие члены команды будут Принимать (Accept) изменения в свои Рабочие пространства Репозитория из этого потока, и поставлять сделанные изменения на Родительский поток.

Личное рабочее пространство пользователя или Рабочее пространство Eclipse (Eclipse Workspace), может иметь свой проверяемый в любое время статус, с помощью интерфейса указывающего на все потенциальные исходящие Наборы изменений (работу, которую пользователь хочет Доставить), а также входящие Наборы изменений (работа, которая выполнена другими членами команды). Пользователи имеют возможность выбрать Наборы изменений либо для Доставки (Наборы изменений становятся доступными для всех членов команды), либо для Принятия (применение Наборов изменений в Поток в свои Рабочие пространства Репозитория и Личное) на индивидуальной основе. Базовые линии (Baselines) для Компонентов также можно создавать, и набор Базовых линий для нескольких Компонентов называется Снимком (Snapshot). Его не следует путать со Статическим представлением в ClearCase, т.к. эти понятия совершенно различны.

Есть ряд тонких различий в том, как системы работают, и это отражается на механизмах взаимодействия пользователей с этими системами. В ClearCase пользователи часто создают Потоки и Ветви для изолирования своей работы. Часто пользователи создают несколько Представлений (рабочих пространств), и один набор изменений выполняется в своем Представлении. С помощью этого изменения могут быть изолированы друг от друга, и обеспечивается отсутствие зависимостей артефактов создаваемых между Наборами изменений. В Jazz пользователь выполняет одно изменение в одно время, в рамках своего Локального рабочего пространства. Пользователи, работающие с несколькими изменениями, имеют выбор, они могут либо создать несколько Локальных рабочих пространств и Рабочих пространств Репозитория или они могут Приостановить (Suspend) работу над одним Набором изменений прежде чем приступить к другим. Возможность Приостановить работу по существу принимает все изменения, связанные с Набором изменений, и сохраняет их в Репозитории, после этого пользователь может Возобновить (Resume) (или вернуться) к этим изменениям в дальнейшем. Рабочее пространство при этом возвращается в состояние, в котором оно находилось, когда был применен предыдущий Набор изменений. Это помогает сократить количество Рабочих пространств, которые разработчику нужно поддерживать.

При использовании ClearCase с ClearQuest и UCM можно связывать с Запись ClearQuest (ClearQuest Record) с Набором изменений. Это требует некоторой настройки и доступности Репозитория ClearCase (VOB) и базы данных CQ. В Jazz/RTC вся эта информация находится в том же хранилище, тут связь создается между Рабочими элементами (Work Item) и Набором изменений. Так как все это построено на основе REST, различные типы объектов Jazz могут быть связаны друг с другом, обеспечивая большую гибкость в связях между артефактами разработки.

Понятие ClearCase Эквивалент Jazz Описание
Check Out/Check In Check In Регистрация изменений в Репозиторий
Activity Change Set Собирает набор изменений файлов в один пакет изменений, обычно связанных с Записью CQ/Рабочим элементом
VOB Jazz Repository Хранит данные в системе управления версиями – один Jazz Репозиторий, несколько VOB-ов
Dynamic View n/a Виртуальное рабочее пространство, содержание которого является динамическим
View Storage Repository Workspace Это не очень хорошее сравнение для Рабочего пространства Репозитория, но хранилище представления на сервере представлений приблизительно похоже
Snapshot View Sandbox/Eclipse Workspace Рабочее пространство, основанное на копировании, используется для разработки
Updating Synchronizing/Accept Обновление рабочего пространства пользователя, когда изменения от других членов команды загружаются в личное рабочее пространство пользователя
Deliver Deliver Продвижение набора изменений из рабочей области в поток, где они становятся общими для всей команды
Rebase Accept Изменения, выполненные другими членами команды, загружаются в личный рабочий поток пользователя
Reserved Check Out Locked Возможность «зарезервировать» ресурс, вы будете являться единственным пользователем, который может изменить ресурс
Baseline Baseline Набор файлов (конфигурация) в рамках компонента в определенный момент времени
Composite Baseline Snapshot Набор различных компонентов, а также конкретная базовая линия в этих компонентах
UCM Process Templates (как Scrum) Стандартно поставляемый процесс, который определяет типы записей/рабочих элементов, связи и процессы, связанные с ними
Stream/Branch Stream Логическое «разделение» кода, обеспечивающее параллельную разработку и изоляцию
Merge Merge Взятие версий одного и того же файла в двух различных ветвях и сопоставление изменений, внесенных в эти файлы
n/a Suspend/Resume Возможность временного хранения или восстановления изменений, сделанных в рабочем пространстве, чтобы вернуть рабочее пространство в некоторую известную конфигурацию

Дополнительная информация

Об авторе

Daniel Toczala является Техническим лидером команды Jazz Jumpstart. Он работал в прошлом с Rational Services в качестве Senior Solutions Architect. Он использовал свой опыт в оказании помощи различным клиентам в осуществлении организационных изменений, чтобы помочь построить концепции шаблонов развертывания. Он сделал многочисленные презентации о том, как организации могут использовать технологий Jazz и Agile подходы в разработке программного обеспечения для повышения качественного результата, который организации по разработке ПО поставляют своим клиентам.

Dan путешествует по миру, помогая клиентам IBM, но его дом в Нью-Хартфорд, штат Нью-Йорк. С ним можно связаться по dtoczala@us.ibm.com.

Posted in ClearCase, IBM Rational, Team Concert | Отмечено: , , , | 11 комментариев »

Почему элементы IBM Rational ClearCase помещаются в директорий lost+found и как их удалить оттуда?

Posted by Шамрай Александр на Ноябрь 12, 2010

<< Перейти в раздел «ClearCase FAQ»

Оригинал: About the lost+found directory

Почему элементы помещаются в директорий lost+found

Объект будет размещен в каталог VOB-а lost+found, когда родительский директорий был удален (в этом случае уже нет контекста, в котором отображается объект) или изменен так, что его содержание не имеет ссылки на предыдущую версию каталога. Это может произойти в следующих случаях:

  • Родительский каталог объекта был удален с помощью команды rmelem и более нигде нет прямых ссылок на объект в версионном хранилище.

Пример:

%>cleartool rmelem dir1
CAUTION! This will destroy the element, all its branches and versions,
including all data, meta-data and history, and will remove the element
from all directory versions that now contain it.  Once you destroy the
element, there will be no way to restore it to its current state.
If you want to preserve the element, but remove references to it from
future directory versions, use the «rmname» command.

Element «dir1» has 1 branches, 2 versions, and is entered
in 1 directory versions.
Destroy element?  [no] y
cleartool: Warning: Object «foo.c» no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as «foo.c.986de380d90b479db49316560deba2f2».
Removed element «dir1».

  • Родительский каталог был изъят на редактирование, были добавлены файлы и/или директории, а затем редактирование директория было отменено (выполнения операция unchecked out).

Пример:

%>cleartool co -nc dir1
Checked out «dir1» from version «/main/7».

%>cleartool mkelem -ci -nc foo.c
Created element «foo.c» (type «text_file»).
Checked in «foo.c» version «/main/1».

%>cleartool unco dir1
cleartool: Warning: Object «foo.c» no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
«foo.c.c7592f61ab0b11db83b5000180f96245».
Checkout cancelled for «dir1».

  • Родительский каталог был изъят на редактирование, были добавлены файлы и/или директории, а затем файл или директорий был удален (rmname) перед тем как новая версия родительского директория была зарегистрирована.

Пример:

%>cleartool co -nc dir1
Checked out «dir1» from version «/main/7».

%>cleartool mkelem -ci -nc foo.c
Created element «foo.c» (type «text_file»).
Checked in «foo.c» version «/main/1».

%>cleartool rmname foo.c
cleartool: Warning: Object «foo.c» no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
«foo.c.c7592f61ab0b11db83b5000180f96245».
Removed «foo.c».

Когда объект перемещается в корень каталога lost+found его OID (идентификатор объекта) добавляется к его оригинальному имени файла. Например:

Оригинальное наименование: foo.c
Наименование в lost+found: foo.c.282d5d339cba4043905da6ca201e1f3d

Если каталог перемещается в lost+found, все подкаталоги и элементы, которые он содержит, перемещаются вместе с ним (структура каталогов сохраняется). Поскольку содержание каталога не помещается в корень lost+found, файлы и директории внутри перемещенного каталога не переименовываются по правилам, описанным выше.

Удаление объектов из lost+found

Прежде чем принимать какие-либо шаги по очистке lost+found VOB-а, пожалуйста, сделайте резервную копию VOB-а.

Есть два возможных способа для удаления объекта из корня lost+found:

    1. Объект может быть перемещен на новое место в VOB-е использованием команды cleartool mv.
    2. Объект может быть полностью удален из VOB.
      • Чтобы переместить объект в новое место, необходимо изъять на редактирование каталог, в который будет помещен объект, и использовать команду cleartool mv <object>.

      См. IBM Rational ClearCase Command Reference команда mv (cleartool man mv) для дополнительной информации.

      Пример:

      % pwd
      /vobs/myvob/lost+found

      % cleartool ls
      test.c.f9e4e356252a11d0a41508000993b102@@/main/1    Rule: /main/LATEST

      % cleartool checkout -nc /vobs/myvob/src

      % cleartool mv test.c.f9e4e356252a11d0a41508000993b102 /vobs/myvob/src/test.c
      Moved «test.c.f9e4e356252a11d0a41508000993b102» to «/vobs/myvob /src/test.c».

      Примечание: Для перемещения необходимо использовать команду cleartool mv, как описано выше, поскольку операция копировать/вставить из Windows Explorer или ClearCase Explorer будет просто создавать приватный файл представления и не будет перемещать элемент.

      • Чтобы удалить объект из VOB-а, используйте команду cleartool rmelem <object>.

      ВНИМАНИЕ: прочитайте нижеприведенное перед выполнением операции

      Осторожно используйте rmelem при удалении элементов или символических ссылок из каталога lost+found. Хотя lost+found, как правило, содержит нежелательные элементы и символические ссылки, в некоторых случаях он может содержать элементы, которые содержаться в другом месте VOB-а (то есть, с родителем), с которыми связаны символические или прямые ссылки. Поэтому, не запускайте rmelem рекурсивно в lost+found без предварительной проверки его содержимого.

      Если необходимо сохранить элемент, который находится в lost+found, перенесите его в другой каталог с помощью команды mv, как описано в предыдущем разделе.

      См. IBM Rational ClearCase Command Reference команда rmelem (cleartool man rmelem) для дополнительной информации.

      Пример:

      Example:

      % pwd
      /vobs/myvob/lost+found

      % cleartool ls
      test.c.f9e4e356252a11d0a41508000993b102@@/main/1    Rule: /main/LATEST

      % cleartool rmelem test.c.f9e4e356252a11d0a41508000993b102


      CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it.  Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the «rmname» command.

      Element «test.c.f9e4e356252a11d0a41508000993b102» has 1 branches, 2 versions, and is entered in 1 directory versions.
      Destroy element?  [no] yes
      Removed element «test.c.f9e4e356252a11d0a41508000993b102».

      Примечание: Если каталог удаляется из lost+found с помощью rmelem, его содержимое будет перемещено в lost+found в том же порядке, который описан в первом разделе выше.

      Если существуют элементы изъятые на редактирование, то изъятие на редактирование должно быть отменено до того, как элемент будет удален из lost+found, см. technote 1259118.

      Использование шаблонов для удаления объектов из lost+found

      Командная строка cleartool в сочетании с шаблонами может быть использована для удаления сразу нескольких элементов из каталога lost+found VOB-а.

      ВАЖНО: Перед выполнением нижеприведенных шагов, Вы должны проверить актуальность файлов в lost+found. Если есть шанс, что эти файлы не должны быть удалены, не используйте эти инструкции. См. раздел Руководства администратора ClearCase The lost+found Directory для дополнительной информации.

      Из представления ClearCase, перейдите в каталог lost+found, запустите командную строку cleartool и вызовите команду rmelem:

      Z:\VOB1\lost+found>cleartool
      cleartool> rmelem *.*

      CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it.  Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the «rmname» command.

      Element «nameapp.c.e83edfb9dfa042db90b83d4417fdec5c» has 1 branches, 2 versions, and is entered in 1 directory versions.
      Destroy element?  [no] yes
      Removed element «nameapp.c.e83edfb9dfa042db90b83d4417fdec5c».

      Примечание: Используйте -force для подавления подтверждения запроса «Destroy element?»:

      cleartool> rmelem -force *.*

      См. Руководство по командам ClearCase по теме rmelem (cleartool man rmelem) для получения информации о поведении rmelem при удалении символической ссылки.

      Удаление нескольких уровней каталогов

      Если существуют каталоги в lost+found, которые должны быть удалены, вам нужно запустить команду rmelem несколько раз.

      Почему?

      • После первой итерации, все элементы, которые были в удаляемом каталоге из lost+found, перемещаются в корень lost+found.
      • Последующие итерации rmelem будут удалять элементы, которые были перемещены в корень lost+found.

      Определение UCM компонента, к которому принадлежит элемент lost+found

      Следующая процедура может быть использована для определения, куда перемещать элементы в случаях, когда есть один или несколько элементов lost+found VOB-а, который содержит много компонентов UCM.

      Примечание: Шаги этой процедуры направлены на поиск корневого каталога UCM компонента и не определяют точный подкаталог компонента, в который элемент должен быть перемещен. Кроме того, эта процедура не будет работать в VOB, который не является Компонентным UCM VOB-ом.

      1. Откройте окно командной строки (Пуск> Выполнить> набрать: cmd.exe)
      2. Перейдите в представление и каталог lost+found конкретного VOB-а
      3. Выполните «cleartool dump -l <element-name>@@», например:
        >cleartool dump -l test.txt.3a99f3b26e9d43bb87e48b981708138c@@test.txt.3a99f3b26e9d43bb87e48b981708138c@@ (3a99f3b2.6e9d43bb.87e4.8b:98:17:08:13:8c)
        M:\mra_EclipseTest\ManyComps\lost+found\test.txt.3a99f3b26e9d43bb87e48b981708138c@@
        oid=3a99f3b2.6e9d43bb.87e4.8b:98:17:08:13:8c dbid=289 (0x121)
        mtype=file element type=9
        stored fstat:
        ino: 0; type: 2; mode: 0444
        usid: NT:S-1-5-21-141845252-1443263951-584457872-1453
        gsid: NT:S-1-5-21-141845252-1443263951-584457872-1023
        nlink: 1; size: 0
        atime: Wed Dec 31 19:00:00 1969
        mtime: Wed Sep 24 07:44:00 2008
        ctime: Wed Sep 24 07:44:00 2008
        returned fstat:
        ino: 289; type: 2; mode: 0444
        usid: NT:S-1-5-21-141845252-1443263951-584457872-1453
        gsid: NT:S-1-5-21-141845252-1443263951-584457872-1023
        nlink: 1; size: 0
        atime: Wed Sep 24 07:44:00 2008
        mtime: Wed Sep 24 07:44:00 2008
        ctime: Wed Sep 24 07:44:00 2008
        master replica dbid=3
        source pool=33 cleartext pool=35
        crde=46
        branches:
        290 \main
        292 \main\mra_EclipseTest

      4. Найдите строку, которая имеет «crde =» и запомните число, которое будет после знака равенства. В приведенном выше примере номер «46» то, что нам нужно. Это идентификатор компонента корневого каталога элемента, который мы будем использовать, чтобы найти компонент, в который элемент должен быть перемещен.
      5. Перейдите в корень VOB-а
        >dir
        Volume in drive M is CCase
        Volume Serial Number is 0234-5789 

        Directory of M:\mra_EclipseTest\ManyComps 

         

        08/28/2007  07:13 AM    <DIR>          .
        09/18/2008  12:03 PM    <DIR>          ..
        08/28/2007  07:13 AM    <DIR>          Comp1
        09/24/2008  07:44 AM    <DIR>          Comp2
        09/24/2008  07:44 AM    <DIR>          lost+found
        0 File(s)              0 bytes
        5 Dir(s)  52,428,800,000 bytes free

      6. Выполните «cleartool dump <sub-directory-name>@@» в одном из поддиректориев компонента. Например:

        >cleartool dump -l Comp1@@ 

        Comp1@@ (ebb32a4a.46224a03.b388.40:71:64:7a:1a:7d)
        M:\mra_EclipseTest\ManyComps\Comp1@@
        oid=ebb32a4a.46224a03.b388.40:71:64:7a:1a:7d dbid=42 (0x2a)
        mtype=directory element type=6
        stored fstat:
        ino: 0; type: 2; mode: 0777
        usid: NT:S-1-5-21-141845252-1443263951-584457872-1453
        gsid: NT:S-1-5-21-141845252-1443263951-584457872-1023
        nlink: 2; size: 0
        atime: Wed Dec 31 19:00:00 1969
        mtime: Tue Aug 28 07:13:57 2007
        ctime: Tue Aug 28 07:13:57 2007
        returned fstat:
        ino: 42; type: 2; mode: 0777
        usid: NT:S-1-5-21-141845252-1443263951-584457872-1453
        gsid: NT:S-1-5-21-141845252-1443263951-584457872-1023
        nlink: 2; size: 0
        atime: Tue Aug 28 07:13:57 2007
        mtime: Tue Aug 28 07:13:57 2007
        ctime: Tue Aug 28 07:13:57 2007
        master replica dbid=3
        source pool=33 cleartext pool=35 derived pool=34
        crde=42
        <cropped>

      7. Найдите строку, которая содержит «crde =» и сравните с числом из шага 4. В данном примере это число «42» и это не тот каталог, который нам нужен.
      8. Повторите шаги 6 и 7, пока не найдете нужный каталог. В этом примере каталог компонента Comp2 с » crde = 46″.
      9. Переместите конкретный элемент в любой каталог в рамках структуры каталогов компонента. Вы должны сделать это из командной строки, изъять на редактирование каталог назначения и установить активность. Например:
        >cleartool lsactivity -cact -cview
        2008-09-24T07:43:58-04:00 20080924test mabushee «20080924test»>cleartool checkout -nco Comp2
        Checked out «Comp2» from version «\main\mra_EclipseTest\2».
        Attached activity:
        activity:20080924test@\Projects «20080924test»

        >cleartool move «lost+found\test.txt.3a99f3b26e9d43bb87e48b981708138c» Comp2\test.txt
        Moved «lost+found\test.txt.3a99f3b26e9d43bb87e48b981708138c» to «Comp2\test.txt».

      10. После выполнения шага 9 зарегистрируйте изменения Вашего целевого каталога.

      Если у вас есть дополнительные элементы в каталоге lost+found, необходимо повторить процедуру для каждого из них.

      Дополнительно

      Posted in ClearCase FAQ, IBM Rational | Отмечено: , , , | Leave a Comment »

      Вложенные UCM Project VOB в ClearCase

      Posted by Шамрай Александр на Август 24, 2010

      Оригинал: Understanding Nested UCM Project VOB Environments

      Введение

      IBM ® Rational ® ClearCase ® Unified Unified Change Management (UCM) позволяет делать расширение с использованием ассоциации административных проектных VOB-ов (PVOB). В этом документе приводятся детали и передовой опыт для сред, которые реализуют структуру административных VOB-ов, которая включает использование нескольких PVOB-ов (вложенные PVOB). В этом документе также рассматриваются дополнительные варианты для среды ClearCase MultiSite. Документ не отображает всех возможных конфигураций с участием UCM PVOB в среде UCM.

      Этот документ предназначен для администраторов ClearCase UCM, ответственных за организацию конфигурации UCM.

      Прежде чем приступить вы должны иметь глубокое понимание общих концепций UCM, которые приведены в разделе Understanding UCM руководства IBM Rational ClearCase Managing Software Projects.

      Обзор

      Вложенные проектные VOB-ы могут добавить дополнительный уровень масштабируемости и функциональности для среды UCM, которая позволяет администраторам разделять метаданные по нескольким проектным структурам UCM. Такая вложенная конфигурация может помочь разделить метаданные между несколькими административными VOB-ами и избежать больших баз данных для VOB-ов. Она также может быть полезна для повышения производительности за счет перевода вновь созданных проектов в отдельные проектные VOB-ы. Эта статья должна помочь избежать многих проблем, которые могут возникнуть при связывании проектных VOB-ов.

      В этом документе будет рассматриваться следующее:

      • Стандартная разработка с одним проектным UCM VOB-ом
      • Создание структуры вложенных проектных VOB-ов
        • Использование существующего проектного VOB-а в качестве административного VOB-а для дочерних проектных VOB-ов.
        • Использование общих административных VOB-ов для нескольких проектных VOB-ов
      • Использование ucmutil link_pvob
      • Среда MultiSite и общие проблемы, которые могут возникнуть

      Стандартная разработка с одним проектным UCM VOB-ом

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

      Ниже на рисунке отображена ассоциация проектного VOB-а и компонентного VOB-а для стандартного UCM. Рисунок отображает некоторые основные данные, сгенерированные в обоих VOB-ах, что более подробно раскрывается ниже.

      Стандартная UCM разработка предполагает, что элементы данных файл и каталог будут созданы в компонентном VOB-е. Каждая версия, сгенерированная в компонентном VOB-е, связывается с UCM активностью. Каждая сгенерированная версия должна быть связана с типом ветви ClearCase.

      Проектный VOB содержит глобальные копии каждого типа ветви необходимых в процессе разработки. Когда создается версия, локальная копия глобальной ветви создается в компонентном VOB-е, которая будет использоваться в дальнейшем для создания версий в этой ветви. Каждая ветвь связана с потоком UCM размещенным в проектном VOB-е. Поток используется для разрешения или ограничения для компонентных VOB-ов при создании версии в связанных глобальных типах ветвей.

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

      Базовая линия UCM является объектом, созданным в рамках проектного VOB-а. Она связана с обычным типом метки, созданным в компонентном VOB-е. Тип метки применяется для единственной последней версии для каждого элемента в выбранной конфигурации. Как правило, эта конфигурация определяется потоком, в котором создается базовая линия.

      Создание структуры вложенных проектных VOB-ов

      Данный раздел описывает добавление нового проектного VOB-а в существующую среду разработки UCM. Новый проектный VOB не содержит существующих проектов или компонентов. Целью создания нового проектного VOB-а является объединение с существующей средой UCM. Если два или более проектных VOB-а связаны в общую административную иерархию VOB-ов, то это называется вложенной структурой проектных VOB-ов. Во вложенной структуре должен быть только один общий административный VOB. Все VOB-ы в административной иерархии VOB-ов должны указывать на один высокоуровневый VOB. На верхнем уровне административный VOB содержит объекты, необходимые для обеспечения создания распределенной UCM разработки.

      На данный момент есть два способа добавления нового проектного VOB-а в существующую среду UCM.

      • Добавить новый проектный VOB и выбрать любой проектный VOB (существующий или новый) в качестве единой административного VOB-а. Однако этот вариант не очень масштабируем. Эта конфигурация представляет риск разрастания одного проектного VOB-а. Это также увеличивает значимость существующего проектного VOB-а.

      Рисунок А.1

      • Добавить новый проектный VOB и новый общий административный VOB. Эта конфигурация становится масштабируемой и предусматривает равное значение для обоих проектных VOB-ов. Это помогает сохранить специфические объекты проектного VOB-а отдельно от общих глобальных метаданных, таких как тип ветви. Такая структура также будет держать метаданные организованными в общем административном VOB-е. Такая конфигурация потребует использования утилиты поставляемой в комплекте с ClearCase. Утилита называется «ucmutil» и далее о ней будет рассказываться более подробно.

      Рисунок А.2

      Использование ucmutil link_pvob

      В выше указанной конфигурации необходимо использование «ucmutil». Утилита имеет подкоманду «link_pvob». Эта подкоманда позволяет администраторам связать существующий проектный VOB с верхнеуровневым административным VOB-ом. Утилита требует, чтоб существующий проектный VOB не был связан с любыми другими административными VOB-ами. Целью этой утилиты является выполнение следующих операций.

      • Передать все существующие глобальные определения типов ветви существующего проектного VOB-а в административный VOB
      • Переопределить ассоциацию всех существующих потоков с глобальными определениями типов ветви перемещенными в административный VOB
      • Перенаправить связи с административным VOB-ом любых соответствующих компонентных VOB-ов к новому административному VOB-у. Как вы можете видеть на рисунке выше, компонентный VOB теперь указывает на общий административный VOB, что является результатом запуска «ucmutil link_pvob». Необходимо также отметить, что ассоциации компонентов остаются с первоначальным проектным VOB-ом.

      Утилиту «ucmutil» можно найти в следующих каталогах:

      • Windows: %CLEARCASE_HOME%\etc\utils\ucmutil.exe
      • Linux/Unix: /opt/rational/clearcase/etc/utils/ucmutil

      Для более подробной информации об этой утилите смотрите Technote 1237620 About ucmutil.

      Примечание: В приведенном ниже примере вы должны установить свой путь к утилите ucmutil в переменную среды (или обеспечить полный путь к ucmutil) и установить контекст в представление для выполнения команд.

      Пример использования:

      ——————————————————————————————————————
      M:\adminView>ucmutil link_pvob -verbose -from vob:\pvobing -to vob:\commonAdminVOB
      Checking branch type ccrc_deliver.
      Checking branch type composite_Integration.
      Checking branch type deliver_Integration.
      Checking branch type william_child_deliver.
      Checking branch type william_child2_deliver.
      Checking branch type william_deliver.
      Total of 6 global branch types in VOB \pvobing.
      Total of 6 UCM branch types checked.
      M:\adminView>
      ——————————————————————————————————————

      Как можно увидеть в приведенном выше примере, подкоманда link_pvob будет находить все глобальные определения типа ветви для дочернего проектного VOB-а. Этот пример выполнен в -verbose (предварительном) режиме. Рекомендуется всегда использовать этот инструмент в режиме предварительного просмотра, перед тем как выполнить саму операцию. Также полезно перенаправить вывод команды в лог-файл для дальнейшего анализа. Эта команда необратима. После выполнения команды запуска с флагом «-fix «, гиперссылка административного VOB изменяется, и все метаданные изменяют структуру для представления иерархических изменений. Существуют некоторые проблемы, которые могут возникнуть в процессе проведения операции, поэтому инструмент проверяет, обеспечена ли блокировка VOB-а с ключом «-nuser». Только пользователь, выполняющий команду, должны быть в состоянии получить доступ к VOB-у при запуске операции «ucmutil link_pvob». Для этого вы должны заблокировать VOB с исключением пользователя, который запустил операцию, с ключом «-nuser».

      Пример блокировки проектного VOB-а с ключом «nuser»:

      ——————————————————————————————————————
      M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
      ucmutil: Error: VOB \pvobing should be locked with «-nuser» before running this tool.

      M:\adminView>cleartool lock -nuser DOMAIN1\william vob:\pvobing
      Locked versioned object base «\pvobing».

      M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
      ucmutil: Error: VOB \commonAdminVOB should be locked with «-nuser» before running this tool.

      M:\adminView>cleartool lock -nuser DOMAIN1\william vob:\commonAdminVOB
      Locked versioned object base «\commonAdminVOB».
      ——————————————————————————————————————

      В приведенном выше примере можно увидеть, что утилита проверяет блокировку обоих проектных VOB-ов. Она будет рекомендовать, чтобы вы заблокировали VOB с ключом -nuser.

      Напомним, что перед запуском ucmutil link_pvob с ключом -fix, вы должны выполнить следующие операции:

      1. Заблокировать проектные VOB-ы с ключом –nuser
      2. Выполнить ucmutil link_pvob –verbose и перенаправить вывод в лог-файл для дальнейшего анализа. (Это также может быть полезно для устранения неполадок)
      3. Убедитесь, что все типы ветвей, перечисленные в режиме предварительного просмотра, имеют локальную мастер реплику на сайте выполняющему операции. (Эта тема будет рассмотрена в разделе Среда MultiSite далее)
      4. Убедитесь, что все компонентные VOB-ы, связанные с дочерним проектным VOB, НЕ заблокированы. Блокировка компонентных VOB не даст утилите доступ и возможность изменить необходимые данные (Вы можете заблокировать компонентные VOB-ы с ключом -nuser при блокировке проектных VOB-ов, чтобы избежать проблем).

      Ниже приведен пример запуска утилиты для связывания проектного VOB-а «\pvobing» с общим административным VOB-ом «\commonAdminVOB»:

      Вот список метаданных перед операцией:

      1. Список глобальных типов ветвей в «\commonAdminVOB»
        M:\adminView>cleartool lstype -s -kind brtype -invob \commonAdminVOB
        main
      2. Список глобальных типов ветвей в «\pvobing»
        M:\adminView>cleartool lstype -s -kind brtype -invob \pvobing
        ccrc_deliver
        composite_Integration
        deliver_Integration
        main
        william_child_deliver
        william_child2_deliver
        william_deliver
      3. Список гиперссылок на административные VOB-ы для ассоциированных компонентных VOB-ов в «\pvobing»
        M:\adminView>cleartool describe -l -ahlink -all vob:\pvobing
        Hyperlinks:
        AdminVOB@42@\brokeComp <- vob:\brokeComp
        AdminVOB@42@\cvobing <- vob:\cvobing
      4. Пример ассоциации потоков UCM с глобальными типами ветвей перед связыванием двух проектных VOB-ов
        M:\adminView>cleartool describe -l -ahlink –all stream:deliver_Integration@\pvobing
        deliver_Integration
        Hyperlinks:
        IndependentGuard@306@\pvobing -> brtype:deliver_Integration@\pvobing
        UseBaseline@114@\pvobing -> baseline:cvobing_INITIAL@\pvobing
      5. Гиперссылка на административный VOB, указывающая из ассоциированного компонентного VOB-а
        M:\adminView>cleartool describe -l -ahlink -all vob:\cvobing
        \cvobing
        Hyperlinks:
        AdminVOB@42@\cvobing -> vob:\pvobing

      Пример выполнения команды связывания двух VOB-ов

      1. Выполнение команды в режиме предварительность просмотра с флагом –verbose и перенаправление вывода в лог-файл:
        M:\adminView>ucmutil link_pvob -verbose -from vob:\pvobing -to vob:\commonAdminVOB > c:\link_pvob_log.txt
      2. Запуск инструмента для создания связи между VOB-ами с флагом –fix:
        M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
        Checking branch type ccrc_deliver.
        Moving branch type ccrc_deliver.
        Checking branch type composite_Integration.
        Moving branch type composite_Integration.
        Checking branch type deliver_Integration.
        Moving branch type deliver_Integration.
        Checking branch type william_child_deliver.
        Moving branch type william_child_deliver.
        Checking branch type william_child2_deliver.
        Moving branch type william_child2_deliver.
        Checking branch type william_deliver.
        Moving branch type william_deliver.
        Reconnecting the moved global branch types.
        There is no global type in source VOB. Do you want to redirect the AdminVOB hyperlink? [no] yes
        Redirecting AdminVOB hyperlink.Total of 6 global branch types in VOB \pvobing.
        Total of 6 UCM branch types checked.
        Total of 6 UCM branch types moved.
        Total of 6 Stream hyperlinks reconnected.
        Total of 2 VOBs has been reconnected to new Admin VOB.

        M:\adminView>

      Ниже представлен список мигрированных и измененных метаданных как результат операции:

      1. Список глобальных типов ветвей, которые сейчас существуют в «\commonAdminVOB»
        M:\adminView>cleartool lstype -s -kind brtype -invob \commonAdminVOB
        ccrc_deliver
        composite_Integration
        deliver_Integration
        main
        william_child_deliver
        william_child2_deliver
        william_deliver

        (Заметьте, что все глобальные типы ветвей, которые до этого существовали в «\pvobing», мигрировали в «\commonAdminVOB»)

      2. Список гиперссылок Admin VOB в «\pvobing» после выполнения ucmutil link_pvob
        M:\adminView>cleartool desc -l -ahlink -all vob:\pvobing
        \pvobing
        Hyperlinks:
        AdminVOB@310@\pvobing -> vob:\commonAdminVOB(Заметьте, что гиперссылки Admin VOB для всех ассоциированных компонентных VOB-ах более не указывает на проектный VOB. Существует только гиперссылка Admin VOB, которая была создана утилитой ucmutil link_pvob)
      3. Пример ассоциации потоков UCM с глобальными типами ветвей после связывания двух проектных VOB-ов:
        M:\adminView>cleartool desc -l -ahlink -all stream:deliver_Integration@\pvobing
        deliver_Integration
        Hyperlinks:
        UseBaseline@114@\pvobing -> baseline:cvobing_INITIAL@\pvobing
        IndependentGuard@306@\pvobing -> brtype:deliver_Integration@\commonAdminVOB(Заметьте, что гиперссылка IndependentGuard сейчас указывает на глобальный тип ветви мигрированный в commonadministrativeVOB)
      4. Список гиперссылок Admin VOB в «commonAdminVOB» после работы утилиты ucmutil
        M:\adminView>cleartool desc -l -ahlink -all vob:\commonAdminVOB
        \commonAdminVOB
        Hyperlinks:
        AdminVOB@43@\brokeComp <- vob:\brokeComp
        AdminVOB@310@\pvobing <- vob:\pvobing
        AdminVOB@225@\cvobing <- vob:\cvobing(Заметьте, что гиперссылки Admin VOB, ранее указывающие на «\pvobing», теперь указывают на «\commonAdminVOB», который содержит все глобальные типы ветвей.)
      5. Измененная гиперссылка Admin VOB, указывающая из компонентного VOB-а ассоциированного с «\pvobing»
        M:\adminView>cleartool desc -l -ahlink -all vob:\cvobing
        \cvobing
        Hyperlinks:
        AdminVOB@225@\cvobing -> vob:\commonAdminVOB(Заметьте, что даже этот VOB, содержащий компонентные данные ассоциированные с «\pvobing», указывает на «\commonAdminVOB» для получения любых определений глобальных типов. )

      MultiSite среды и общие вопросы, которые могут возникнуть

      На данный момент мы рассмотрели, как работает утилита ucmutil link_pvob для создания вложенные структуры проектных VOB-ов, однако, мы не обсуждали то, что может произойти если VOB реплицирован в среде ClearCase MultiSite.

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

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

      1. Сайт реплики не будет иметь доступ к необходимым глобальным типам ветвей связанными с потоками UCM
      2. На сайте реплики, скорее всего, будет необходимость создания потоков. Потоки не будут иметь доступ к общему административному VOB-у, где находятся связанные с ними глобальные типы ветвей.
      3. Проектный VOB и компонентный VOB будут иметь неверные гиперссылки на административный VOB, указывающие на VOB, который не существует.
        ВАЖНО: Это очень опасно. Если «cleartool checkvob –ucm или -hlinks» исполняется для VOB-а, команда увидит поврежденные гиперссылки. Checkvob фактически удалит гиперссылки для исправления. Эта операция будет реплицирована на исходный сайт. Это нарушит структуру административного VOB-а на исходном сайте и вызовет катастрофу в производственной среде. Эта ошибка не произойдет, если все VOB-ы в структуре будут реплицироваться. Как альтернатива, при необходимости, можно блокировать тип гиперссылки AdminVOB для VOB-ов с ключом -nuser. Это запретит пользователям создавать и удалять гиперссылки AdminVOB.Пример:
        cleartool lock –nuser domain\user hlink:AdminVOB@\pvobing

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

      Перед запуском ucmutil link_pvob с флагом «-fix» в среде MultiSite, вы должны предусмотреть следующие.

      1. Убедитесь, что все доступные метаданные имеют мастер реплику сайта, на котором выполняется команда ucmutil.
      2. Запустите сначала программу с флагом «-verbose» и просмотрите список вовлеченных ветвей. Убедитесь, что все потоки связаны с этими типами ветвей имеют мастер реплику сайта, на котором выполняется команда. Используйте страницу помощи «cleartool chmaster» для изменения мастер реплики потока и всех его объектов.
      3. Просмотрите гиперссылки AdminVOB, связанные с существующим проектным VOB-ом, чтобы определить для каких VOB-ов должна быть установлена мастер реплика сайта, на котором выполняется команда. Гиперссылки AdminVOB связанные с каждым компонентным VOB-ом будут заново созданы, чтобы они указывали на новый связанный общий административный VOB.
      4. При запуске ucmutil link_pvob с флагом «-fix», сохраните результаты, т.к. они могут быть использованы для устранения ошибок, которые могут произойти. Для перенаправления вывода команды вы не можете быть в командной строке ucmutil. Вы должны набирать команду из контекста представления ClearCase. Вы должны отслеживать стандартные ошибки на стандартном устройстве вывода. Пример ниже покажет только стандартный поток вывода. Стандартные ошибки будут отображаться в окне командной строки.Пример:
        M:\adminView>ucmutil link_pvob –fix –from vob:\pvobing –to vob:\commonAdminVOB > c:\linkPvob_runLog.txt

      Заключение

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

      Ссылки

      IBM Rational ClearCase Managing Software Projects manual

      В тему статьи Using multiple PVOBs

      Posted in ClearCase | Отмечено: , , , , , , | Leave a Comment »

      Атомарный Check In для ClearCase

      Posted by Шамрай Александр на Июнь 29, 2010

      << Перейти в раздел «ClearCase FAQ»

      Начиная с версии IBM Rational ClearCase 7.1.1, поддерживается атомарная регистрация изменений в хранилище версий. Суть ее заключается в том, что если выполняется check in для группы файлов и для одного или нескольких файлов не могут быть созданы новые версии (например, не удовлетворяют внутренним политикам организации), то новые версии ни для одного из файлов не будут зарегистрированы (не будет выполнена операция check in).

      Для того чтоб атомарный check in поддерживался, его необходимо активировать для хранилища версий, т.к. по умолчанию он отключен. Для этого необходимо выполнить команду cleartool protectvob с опцией -atomic_checkin.

      >cleartool protectvob -atomic_checkin \TestVob

      VOB «\TestVob» set to enable atomic checkin.

      Ниже представлен пример использования атомарного check-in.

      Были изъяты на изменение два файла «n1.txt» и «n2.txt». Для первого файла были выполнены изменения, а второй остался без изменений. Для обоих файлов выполняется регистрация изменений с параметром –atomic. В результате оба файла остались в состоянии check out.

      >cleartool checkin -nc -atomic n1.txt n2.txt

      cleartool: Error: By default, won’t create version with data identical to predecessor.

      cleartool: Error: Unable to complete atomic checkin.

      Если внести изменения во второй файл и повторить операцию check in, то она успешно пройдет.

      >cleartool checkin -nc -atomic n1.txt n2.txt

      Checked in «n1.txt» version «\main\3».

      Checked in «n2.txt» version «\main\3».

      Posted in ClearCase FAQ, IBM Rational | Отмечено: , , , | Leave a Comment »

      Есть ли интеграция Eclipse и ClearCase?

      Posted by Шамрай Александр на Март 31, 2010

      << Перейти в раздел «ClearCase FAQ»

      Такая интеграция существует и ее можно скачать с этой страницы: IBM Rational ClearCase plug-ins. Интеграция включают следующие плагины (при это ClearCase должен быть установлен на локальной машине):

      • ClearCase SCM Adapter – плагин, который обеспечивает доступ ко всем функциям ClearCase из Eclipse.
      • ClearCase MVFS Adapter – плагин, который обеспечивает взаимодействие с динамическими представлениями.

      Процедура установки для плагинов будет следующая (для версии Eclipse 3.5):

      1. Распаковать скачанные архивы с плагинами.
      2. Перейти в Eclipse в меню «Help > Install New Software…» и нажать в новом окне «Install» кнопку «Add…«.
      3. В появившемся окне нажать кнопку «Local…«.
      4. Выбрать папку «eclipse» распакованного архива с плагином и нажать «Ok«.
      5. Нажать снова «Ok«.
      6. Проверить, чтобы не был отмечен пункт «Group items by category«.
      7. Выбрать доступные плагины для установки и нажать «Finish».
      8. Перезапустить Eclipse.

      В результате в меню Eclipse появиться пункт ClearCase с доступными функциями:

      Кроме этого при нажатии правой кнопкой мыши на файлах проекта в меню «Team» также будут доступны функции ClearCase:

      Posted in ClearCase FAQ, IBM Rational | Отмечено: , , , , | Leave a Comment »

      БЕСПЛАТНЫЙ семинар 30 сентября в Санкт-Петербурге: «Эффективное использование технологи IBM Rational и Microsoft для улучшения процессов разработки ПО: идеология, практика и методология»

      Posted by Шамрай Александр на Сентябрь 8, 2009

      Компании СМ-Консалт и  Legal SoftWaveTM  приглашают Вас посетить БЕСПЛАТНЫЙ семинар «Эффективное использование технологи IBM Rational и Microsoft для улучшения процессов разработки ПО: идеология, практика и методология».Семинар состоит из трех частей. Первая часть посвещена программному обуспечению IBM Rational, вторая часть посвещена Microsoft.
      Третья часть — круглый стол, где можно будет пообщаться с докладчиками. На семинаре специалисты СМ-Консалт расскажут о технологиях  IBM Rational и Microsoft, поделятся практическим опытом использования и внедрения методологии и технологии IBM Rational и Microsoft.

      Планируемая продолжительность семинара — 8 часов. В конце семинара будет проведён «круглый стол» по затронутым темам и расширенная сессия вопросов и ответов.  

      Управление процессами разработки и сопровождения информационных систем в IT-подразделениях становится критичным направлением развития крупных компаний. Семинар посвящен вопросам эффективного управления проектами и процессами разработки прикладного программного обеспечения на основе методологии и технологий IBM Rational и Microsoft.

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

      • Экономический эффект от внедрения IBM Rational и Microsoft для компаний различного масштаба;
      • Улучшение процессов разработки и сопровождения за счет качественной постановки процессов;
      • Обзор инструментов и методологии IBM Rational и Microsoft: теория и практика внедрения.

      Участие в семинаре БЕСПЛАТНОЕ
      ЗАРЕГИСТРИРОВАТЬСЯ —>

      Программа семинара: 

        Наименование доклада

      Докладчик                                                                               
      9:00—09:30      
       Регистрация участников, кофе  
      09:30 —  09:35 Открытие семинара  
      09:30 10:45  Офис управления проектами как организационно-аналитический центр предприятияПереход от выполнения процессов к предоставлению востребованных внутри Вашей организации сервисов 

      • Новые экономические условия — новые вызовы к деятельности проектного офиса;
      • Возможные сценарии развития проектного офиса на изменения в бизнес окружении;
      • Предоставление сервисов другим подразделениям как основа выживания проектного офиса;
      • Оценка экономического эффекта от трансформации проектного офиса в организационно-аналитический центр организации;
      • Программа практических шагов по развитию функций и программной инфраструктуры проектного офиса.
      «Эдд Вэлью». Алексей Федорищев,

      MBA, PMP, руководитель проектного офиса
      10:45 13:30
      (с перерывом)
       Решения IBM Rational для управления жизненным циклом разработки и сопровождения программных систем  Обзор средств IBM Rational:

      • Управление требованиями;
      • Управление изменениями и релизами;
      • Управление качеством;
      • Управление программными активами.

       

      Рассматриваются инструменты: IBM Rational ClearCase, ClearQuest, RequisitePro, Method Composer, Software Architect, Robot, APPScan и другие

      Практика и примеры внедрения IBM Rational

      Оценка эффективности от внедрения и использования методологии и инструментальных средств. 

      М-Консалт. Александр Новичков
      Руководитель отдела консалтинга
      13:30 — 14:30
      Ответы на вопросы, обед
       
      14:30 — 16:20
      (с перерывом)
      Решения Microsoft Team System 2010 для управления жизненным циклом разработки и сопровождения программных систем

      • Обзор архитектуры и вариантов установок;
      • Обзор шаблонов процессов;
      • Управление версиями, изменениями, сборкой;
      • Тестирование, отчетность. 

      Оценка эффективности от внедрения и использования методологии и инструментальных средств.

      СМ-Консалт. Александр Шамрай
      Руководитель отдела перспективных разработок
      15:45 — 16:45 Круглый стол СМ-Консалт. Александр Новичков
      Руководитель отдела консалтингаСМ-Консалт. Александр Шамрай
      Руководитель отдела перспективных разработок 

      Участие в семинаре БЕСПЛАТНОЕ
      ЗАРЕГИСТРИРОВАТЬСЯ —>


      Место проведения семинара: Санкт-Петербург, Бизнес-центр «Сенатор» на 7-ой линии ВО, д. 76

       

      О компаниях-устроителях семинара:

       Компания  «СМ-Консалт»
      создана в 2004 году. Основные направления деятельности компании — консалтинг в области управления проектами, поддержка и внедрение технологий и инструментария IBM Rational. Поставка, настройка и последующее сопровождение программного обеспечения IBM Rational и Microsoft.
      «СМ-Консалт» входит в пятерку лидирующих консалтинговых компаний России, занимающихся внедрением IBM Rational.
      Сотрудниками компании проведено более 20 успешных проектов внедрения IBM Rational, обучено более 700 специалистов , как в России, так и в СНГ.
      «СМ-Консалт» является бизнес-партнером IBM и имеет статус Advanced IBM Partner.
      Основу компании составляют только сертифицированные профессионалы и эксперты, чей опыт и знания не вызывают сомнений.
      В числе клиентов «СМ-Консалт» такие крупные компании как: Банк Траст, Банк Русский Стандрат, Татнефть, ВнешТоргБанк, Иркутский Авиазавод, Русский Алюминий, ЗАО «АйТи» и многие другие
      Компания  «СМ-Консалт» рекомендована Microsoft d в качестве поставщика сервисных услуг по развертыванию, настройке и обучению MS TeamSystem.

      Компания Legal SoftWaveTM 
      ведёт свою деятельность с начала 2008 года. Основное направление — лицензирование программного обеспечения и IT-консалтинг в области лицензирования продуктов для компании IT-сектора. Компания является сертифицированным партнером компании Microsoft® по направлению License Delivery и Software Asset Management. И рекомендована Microsoft для работы с компаниями разработчиками программного обеспечения.
      Отличительные качества компании высокий профессионализм и уровень сопровождения. За время существовании компании проведено более 25 проектов в области лицензирования. 100% постоянных специалистов компании являются MCP в области лицензирования продажи продуктов.

      О докладчиках:

       

      Новичков Александр Николаевич

       090809_1159_1.jpg

      Генеральный директор консалтинговой компании «СМ-Консалт».
      Работает в области информационных технологий с 1994 года. Является руководителем отдела консалтинга и внедрения Microsoft и IBM. Участвовал более чем в 20 успешных проектах внедрения Microsoft и IBM в таких организациях как Банк внешней торговли, ОАО «Татнефть», Национальный банк «ТРАСТ», Банк «Русский стандарт», ОАО «Иркут Авиа», ЗАО «АйТи», ЗАО «Аплана», Сбербанк России, Центральный банк Российской Федерации, ОАО «Русский алюминий» и многих других. Имеет более 30 публикаций научных и научно-популярных материалов. За время работы в консалтинге им обучено более 500 специалистов ведущих IT-компаний России и СНГ. Является руководителем отдела внедрения и консалтинга в компании «СМ-Консалт».

      Шамрай Александр Владимирович

       090809_1159_2.jpg

      Руководитель отдела перспективных разработок «СМ-Консалт».
      Занимается внедрением и адаптацией процессов управления изменениями и конфигурациями, управления проектами разработки ПО на основе инструментов Microsoft Team System и IBM Rational. Участвовал в проектах внедрения инструментов командной разработки ПО, адаптации и формализации процессов разработки ПО в следующих компаниях: Национальный Банк Траст, ОАО Банк ВТБ, Банк Русский стандарт, Сбербанк, ОАО Татнефть. Занимается преподавательской деятельностью в области управления изменениями и конфигурациями, управления проектами разработки ПО с использованием Microsoft Team System и IBM Rational. Регулярно публикуется на сайтах Microsoft и IBM по методам и практикам применения инструментов командной разработки.

      Posted in Новости, Семинары | Отмечено: , , , , , , , , , , , | 1 Comment »

      Увеличение производительности ClearCase

      Posted by Шамрай Александр на Август 28, 2009

      По сути все что нужно для управления конфигурациями в ClearCase уже есть. Поэтому все усилия IBM Rational в развитии этого продукта вкладывает в увеличении производительности его основных операций. Недавно появился обзор на сайте IBM, который показывает, что улучшилось в версии IBM Rational ClearCase 7.1 в отношении производительности. Если кратко, то в версии 7.1 были сделаны серьезные доработки по улучшению работы службы Atria Location Broker Daemon (ALBD), которая является основным компонентом в клиент-серверной архитектуре ClearCase и отвечает за производительность основных операций, увеличена производительность операций на сервере регистраций и сделаны доработки по улучшению скорости работы удаленного клиента ClearCase (CCRC). Документ смотрим здесь.

      Posted in ClearCase, IBM Rational | Отмечено: , , | Leave a Comment »

      Семинар 10 сентября в Санкт-Петербурге по сравнению возможностей IBM Rational и MS Team System

      Posted by Шамрай Александр на Июль 29, 2009

      Давно хотели провести мероприятие, семинар, тренинг или что-то подобное, для того, чтобы в одном месте продемонстрировать решения IBM Rational и Microsoft.

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

      Идея данного семинара проста: взять и показать инструменты обоих производителей работают в схожих задачах. То есть мы попробуем взять некие реальные практические задачи и “пропустим” их через средства IBM Rational и Microsoft.

      Ну, и, собственно, постараемся ответить на все вопросы аудитории.

      Посмотреть программу и записаться можно по ссылке ниже

      Уникальный семинар 10 сентября в Санкт-Петербурге:”Эффективное использование технологи IBM Rational и Microsoft для улучшения процессов разработки ПО: идеология, практика и методология. Выбор оптимальной платформы.”

      Posted in Новости, Семинары, IBM Rational, Microsoft | Отмечено: , , , , , , , , , , , | 1 Comment »

      Графическое руководство по командам ClearCase

      Posted by Шамрай Александр на Июль 26, 2009

      В интернете хватает уже исчерпывающих руководств по ClearCase. Но одна из сложностей команд ClearCase – это большое количество параметров, в последовательности которых путаются даже опытные менеджеры ClearCase. Сегодня нашел интересный ресурс, который в отличии от стандартных мануалов, описывает не только набор параметров для команд, но и рисует графическое представление их последовательности. Адрес сайта: http://www.samecs.com/commands.htm

       

      Posted in ClearCase, IBM Rational | Отмечено: , , | Leave a Comment »

       
      %d такие блоггеры, как: