 | Уровень сложности: средний Рустам Зайдуллин, ведущий инженер, ТатАСУнефть" ОАО "Татнефть"
Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт
01.04.2009 При внедрении управления конфигурациями и, соответственно, инструментария версионного хранения менеджеры проектов нередко задают вопросы об ограничении доступа на внесение изменений в исходные коды, которые теперь оказались вынесенными в версионное хранилище.
При внедрении управления конфигурациями и, соответственно, инструментария версионного хранения менеджеры проектов нередко задают вопросы об ограничении доступа на внесение изменений в исходные коды, которые теперь оказались вынесенными в версионное хранилище, к которому, несомненно, имеют доступ больше специалистов, чем к каталогу с исходным кодом на жёстком диске разработчика. Это желание менеджера контролировать новый процесс вполне понятно и законно, так как человек несёт ответственность за конечный результат, и появление потенциального источника рисков внесения неконтролируемых на начальном этапе изменений в исходные тексты не может его не беспокоить несмотря на снижение многих других рисков, в частности, сохранения всех промежуточных версий, централизованного архивирования и сохранения истории изменений. Традиционно для определения прав доступа к каталогам и элементам версионного хранилища в ClearCase используются доменные группы, в которые необходимо внести всех специалистов – участников процесса изменения. После создания группы средствами интерпретатора командной строки cleartool каталогу устанавливается уровень доступа – только для членов созданной группы. Этот вариант вполне хорош при разовом выполнении, например, при создании версионного хранилища, но для установки дополнительных правил доступа может быть неудобен по ряду причин, например, дополнительное звено в лице администратора домена, таймаут на обновление доменных настроек. Если в организации строго регламентирован процесс изменения доменных настроек, что на сегодня зачастую имеет место, то добавление новому специалисту прав на изменение исходного кода становится слишком затратной по времени и числу привлекаемых специалистов операцией. Поэтому когда в очередной раз очередной лидер разработчиков задал вопрос о том, сможет ли он сам ограничить доступ на изменение исходных кодов по своему усмотрению, мы поставили себе задачу предоставить ему такую возможность (рисунок 1).
Рисунок 1. Ограничение доступа на изменение содержимого каталога
Разработанное решение состоит из триггера, срабатывающего перед выполнением операции CheckOut, и файла, содержащего список путей к каталогам, для которых ограничен доступ, и соответствующих этим путям учётных записей разработчиков, работающих в версионном хранилище и имеющих доступ на изменение содержимого этих каталогов. При попытке перевода элемента версионного хранилища в редактируемое состояние триггер срабатывает и выполняет проверку, входит ли элемент в число элементов с ограниченным уровнем доступа, и имеет ли в этом случае разработчик право на изменение этого элемента. Пути к каталогам с ограниченным доступом прописываются полностью, начиная с корневого каталога версионного хранилища. Для передачи в тело триггера имени пользователя и пути к элементу версионного хранилища используются переменные ClearCase – CLEARCASE_PN и CLEARCASE_USER. Структура файла со списком настроек определения доступа проста – каждая строка содержит путь от корневого каталога версионного хранилища непосредственно к каталогу, для которого устанавливается правило доступа, и далее указывается список разработчиков, которые имеют право на внесение изменений во вложенные в каталог элементы. Файл с описанием политик доступа помещается под версионное хранение в корневой каталог хранилища, права на его изменение даются только администратору системы версионного хранения, лидеру разработчиков, и специалистам, которых определяет менеджер. Для снижения вероятности опечатки при записи нового правила и для повышения удобства использования описанного решения был разработан дополнительный скрипт, встроенный в контекстное меню браузера ClearCase и выполняющий запись нового правила в файл.
Рисунок 2. Вызов скрипта для создания правила доступа
Рисунок 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;
|
Считываем в массив строки из файла с правилами доступа. Каждая строка содержит описание правил доступа к одному каталогу, для которого дополнительные ограничения были введены:
Построчно обрабатываем все строки файла:
Определение позиции в строке символа табуляции:
$path=substr($line, 0, $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_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
|
Об авторах | | | Зайдуллин Рустам работает в области информационных технологий с 2005 года. Имеет опыт адаптации и внедрения RUP и инструментальных средств IBM Rational. Сертифицированный специалист по следующим продуктам: IBM Rational ClearCase, Microsoft Project 2003. Является ведущим инженером группы контроля качества процессов разработки программного обеспечения управления "ТатАСУнефть" ОАО "Татнефть". |
| | | Новичков Александр работает в области информационных технологий с 1994
года. Является руководителем отдела консалтинга и внедрения IBM
Rational. Участвовал более чем в 20 успешных проектах внедрения IBM
Rational в таких организациях как Банк внешней торговли, ОАО «Татнефть»,
Национальный банк «ТРАСТ», Банк «Русский стандарт», ОАО «Иркут Авиа»,
ЗАО «АйТи», ЗАО «Аплана», Сбербанк России, Центральный банк Российской
Федерации, ОАО «Русский алюминий» и многих других. Имеет более 30
публикаций научных и научно-популярных материалов. Является
сертифицированным специалистом по следующим продуктам IBM Rational:
ClearCase for Windows, ClearQuest for Windows и UCM Essentials. За время
работы в консалтинге им обучено более 500 специалистов ведущих
IT-компаний России и СНГ. Является руководителем отдела внедрения и
консалтинга в компании СМ-Консалт (www.cmcons.com). Связаться с ним
можно по адресу rational.tools.info@gmail.com |
Выскажите мнение об этой странице
| |
