СМ-Консалт
 

Триггеры ClearCase: Создание гибкой системы распределения доступа к элементам версионного хранилища

Статьи Управление конфигурациями и изменениями (ALM)

Триггеры ClearCase: Создание гибкой системы распределения доступа к элементам версионного хранилища

 

Уровень сложности: средний

Рустам Зайдуллин, ведущий инженер, ТатАСУнефть" ОАО "Татнефть"
Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт

01.04.2009

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

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

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

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

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


Рисунок 1. Ограничение доступа на изменение содержимого каталога
Рисунок 1. Ограничение доступа на изменение содержимого каталога

Разработанное решение состоит из триггера, срабатывающего перед выполнением операции CheckOut, и файла, содержащего список путей к каталогам, для которых ограничен доступ, и соответствующих этим путям учётных записей разработчиков, работающих в версионном хранилище и имеющих доступ на изменение содержимого этих каталогов. При попытке перевода элемента версионного хранилища в редактируемое состояние триггер срабатывает и выполняет проверку, входит ли элемент в число элементов с ограниченным уровнем доступа, и имеет ли в этом случае разработчик право на изменение этого элемента. Пути к каталогам с ограниченным доступом прописываются полностью, начиная с корневого каталога версионного хранилища. Для передачи в тело триггера имени пользователя и пути к элементу версионного хранилища используются переменные ClearCase – CLEARCASE_PN и CLEARCASE_USER.

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

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


Рисунок 2. Вызов скрипта для создания правила доступа
Рисунок 2. Вызов скрипта для создания правила доступа


Рисунок 3. Ввод имён пользователей с правом доступа на изменение
Рисунок 3. Ввод имён пользователей с правом доступа на изменение

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

Далее – описание обоих скриптов с комментариями.

												$fail="M:\\$ENV{CLEARCASE_VIEW_TAG}\\$ENV{CLEARCASE_VOB_PN}\\access.txt";

Формируем в переменной полный путь к файлу с описанием правил доступа. Так как название View у каждого пользователя своё, необходимо определять путь посредством переменной среды CLEARCASE_VIEW_TAG.

												$cur_path=$ENV{CLEARCASE_PN};

Записываем в переменную путь к элементу, на котором сработал триггер:

												$cur_path=substr($cur_path, 3);

$beg=index($cur_path,"\\");

$cur_path=substr($cur_path, $beg+1);


Обрабатываем переменную с путём – отсекаем имя тома, логического диска MVFS, и название View разработчика:

												open(FL, $fail) || die "Can't open file \n";

$i=0;

while (<FL>)

{

@lines[$i]=split(FL);

$i=$i+1;

};

close FL;


Считываем в массив строки из файла с правилами доступа. Каждая строка содержит описание правил доступа к одному каталогу, для которого дополнительные ограничения были введены:

												foreach $line (@lines)

{


Построчно обрабатываем все строки файла:

												    $tab=index($line, "\t");

Определение позиции в строке символа табуляции:

												    	$path=substr($line, 0, $tab);

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

												    $tab++;

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

												    $names=substr($line, $tab);

Присваиваем переменной часть строки, содержащую имена учётных записей, имеющих право на изменение элементов каталога:

												    if ($cur_path =~ $path)

{


Проверяем, принадлежит ли обрабатываемый элемент каталогу, для которого заданы особые условия доступа:

														if ($names =~ $ENV{CLEARCASE_USER})

{

exit(0);

}


Если учётная запись указана в списке имеющих право на изменение элементов каталога,триггер завершает работу:

														else

{

$ent = system("clearprompt proceed -newline -type error -mask proceed -prompt

\"У вас нет прав на изменение этого элемента!\n

Обратитесь к менеджеру проекта\" -prefer_gui ");

exit(1);

};

};

};

exit(0);


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

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

												$path_d=@ARGV[0];

Присвоение переменной входного параметра – путь к каталогу:

												$path_f="M:\\DEV_View\\ARC\\access.txt";

Запись в переменную пути к файлу с настройками:

												prompt: $string="clearprompt text -outfile names.tmp -prompt 

\"Введите через пробел названия учётных записей с правом доступа\"";

$lab=system(" $string ");

if ($lab != 0) {

Win32::MsgBox("Операция прервана пользователем");

die "";

};


Вывод диалога для ввода названия учётных записей разработчиков с правом доступа:

												open(FL, "names.tmp") || die "Can't open file \n";

$i=0;

while (<FL>)

{

@pas[$i]=split(FL);

$i=$i+1;

};

close FL;

$names=$pas[0];


Считывание введённого значения:

												if ($names eq "") {

goto prompt ;

};


Если введено пустое значение – возврат к диалогу:

												$path_d=substr($path_d, 3);

$beg=index($path_d,"\\");

$path_d=substr($path_d, $beg+1);


Отсечение названия тома логического диска MVFS и названия View:

												$rule=$path_d."\t".$names."\n";

Формирование строки с правилом – путь к каталогу, разделитель – знак табуляции, список разработчиков с правом доступа, знак перевода строки:

												system("cleartool checkout -c 

\"Добавление правила доступа: $rule\" \"$path_f\" ");

open(FILE, ">>$path_f") || die "Can't open file \n";

print FILE "$rule";

close FILE;

system("cleartool checkin -nc \"$path_f\" ");


Запись в файл с настройками, находящийся под версионным контролем, нового правила.

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

Полный листинг скрипта триггера

												$fail="M:\\$ENV{CLEARCASE_VIEW_TAG}\\$ENV{CLEARCASE_VOB_PN}\\access.txt";



$cur_path=$ENV{CLEARCASE_PN};

$cur_path=substr($cur_path, 3);

$beg=index($cur_path,"\\");

$cur_path=substr($cur_path, $beg+1);





open(FL, $fail) || die "Can't open file \n";

$i=0;

while (<FL>)

{

@lines[$i]=split(FL);

$i=$i+1;

};

close FL;



foreach $line (@lines)

{

$tab=index($line, "\t");



$path=substr($line, 0, $tab);

$tab++;

$names=substr($line, $tab);



if ($cur_path =~ $path)

{

if ($names =~ $ENV{CLEARCASE_USER})

{

exit(0);

}

else

{

$ent = system("clearprompt proceed -newline -type error -mask proceed -prompt

\"У вас нет прав на изменение этого элемента!\n

Обратитесь к менеджеру проекта\" -prefer_gui ");

exit(1);

};

};

};

exit(0);


Полный листинг скрипта для контекстного меню

												$path_d=@ARGV[0];

$path_f="M:\\DEV_View\\ARC\\access.txt";



prompt: $string="clearprompt text -outfile names.tmp -prompt

\"Введите через пробел названия учётных записей с правом доступа\"";

$lab=system(" $string ");

if ($lab != 0) {

Win32::MsgBox("Операция прервана пользователем");

die "";

};



open(FL, "names.tmp") || die "Can't open file \n";

$i=0;

while (<FL>)

{

@pas[$i]=split(FL);

$i=$i+1;

};

close FL;

$names=$pas[0];



if ($names eq "") {

goto prompt;

};



$path_d=substr($path_d, 3);

$beg=index($path_d,"\\");

$path_d=substr($path_d, $beg+1);





$rule=$path_d."\t".$names."\n";



system("cleartool checkout -c \"Добавление правила доступа: $rule\" \"$path_f\" ");



open(FILE, ">>$path_f") || die "Can't open file \n";

print FILE "$rule";

close FILE;



system("cleartool checkin -nc \"$path_f\" ");


Формат файла описания правил доступа

														

src\modul_a\sub_modul_1\ Developer1, Developer2, Developer3

src\modul_b\sub_modul_2\ Developer1, Developer2

src\modul_b\sub_modul_3\ Developer2, Developer3, Developer4

07.04.2009

Комментарии

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Бесплатный вебинар 14 декабря в 14 00 по Мск - «Секреты управления ИТ-командой: 10 важных практик, которые сделают команду эффективной»

Новые статьи в библиотеке

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Отчет, презентация и видео доклада для Октябрьской встречи Петербургского клуба менеджеров проектов в IT - SPM Meetup #36

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2016.
Карта сайта