Блокировки элементов разработки. Варианты использования

Введение

В данной статье я хочу рассказать о том, как можно использовать одно из новшеств версии DIRECTUM 5.1 - блокировки элементов разработки.

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

Общая информация о новом функционале

Вот несколько ссылок где собрана информация о новом функционале:

1. Статья Новинки DIRECTUM 5.1 для разработчиков.
2. Описание блокировок элементов разработки в справке.

Несколько тезисов о новом функционале:

1. Функционал блокировок элементов разработки можно включать и отключать, для этого есть установка системы DevelopmentComponentLockEnabled.
2. Устанавливать блокировку может любой пользователь с привилегией «Разработка системы».
3. Снять блокировки, установленные другими разработчиками, могут только пользователи с привилегией «Управление блокировками элементов разработки».
4. При импорте разработки есть возможность снимать блокировки, для этого появился соответствующий параметр в диалоге «Параметры импорта». Отображается только при включенном механизме блокировки.
5. Блокировки можно снимать при экспорте разработки, для этого добавлен параметр в диалоговое окно «Параметры экспорта». Отображается только при включенном механизме блокировки.
6. Существует возможность автоматизации установки и снятия блокировок, для этого появился метод, возвращающий объект IDevelopmentComponentLock. Через этот объект можно программно устанавливать и снимать блокировки, получать информацию о блокировке.

Проблемы коллективной разработки

Мне доводилось вести разработку одного достаточно крупного функционала, при этом разработку вместе со мной вело порядка 5-6 разработчиков. Вот небольшой список проблем, с которыми мы сталкивались:

1. Поняв где именно ошибка в коде, довольный собой, разработчик не задумываясь исправлял все, что необходимо (событие в справочнике, функцию которая выдает некорректный результат, функцию внутри функции). На следующий день, перед переносом в тестовую базу, разработчик не находил свой код, а по истории видел, что его коллега сохранил ту же функцию, что и он, но чуть-чуть позже… Я думаю многие сталкивались с такой ситуацией.
2. Исправив очередное замечание в коде, предварительно проверив исправление в базе разработки, разработчик, уверенный что все хорошо, переносит исправления в базу тестирования. Тестировщик начинает проверять что получилось. Далее следует множество нехороших слов в адрес разработчика. Не понимая, что происходит, он подключается к базе тестирования и видит жуткую картину. Оказывается, в справочник, который разработчик переносил, его коллега несколько дней назад добавил новую функцию, а он не зная о ее существовании просто взял и перенес разработку в тест (ладно хоть не в прод…).
3. Были у нас и случаи, когда разработчик просто забывал закрыть редактор кода на день, а потом на следующий день сохранял свои изменения. Само собой, он при этом затирал разработку свои коллег.
4. Очень часто возникала ситуация, когда я открываю историю работы с компонентой перед внесением изменений, вижу, что вчера мой коллега что-то в ней изменял. Я начинаю искать этого человека, писать ему, узнавать, что он делал, что изменял и могу ли я начать свои доработки или ему компонента еще нужна.

Это небольшой список проблем, которые возникали в моей практике.

Варианты использования

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

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

1. Блокируем все элементы разработки, которые модифицируем. В комментарии к блокировке желательно кратко написать какой функционал реализуется, плановую дату освобождения компоненты. Одинаковый комментарий к блокировкам компонент может быть полезен при экспорте разработки.
2. Не снимаем блокировку до тех пор, пока работа над функционалом не закончена.
3. При смене исполнителя модификаций, блокировку нужно менять сразу на нового исполнителя. Не нужно оставлять компоненту незаблокированной.
4. Привилегией «Управление блокировками элементов разработки» должен обладать узкий круг пользователей.

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

1. Заходим в базу разработки. Составляем список компонент, которые будем модифицировать.  Удостоверяемся что нет заблокированных компонент.
2. Блокируем все планируемые для изменения компоненты.
3. Выполняем модификации.
4. Отправляем на рецензию. Тут есть два варианта, либо мы сами меняем блокировку на имя рецензента, либо рецензент обладает привилегией «Управление блокировками элементов разработки» и сам меняет ее на свое имя.
5. Рецензент выполняет рецензию, меняет блокировку обратно на имя разработчика.
6. Разработчик переносит разработку в базу тестирования (в экспорте разработки может помочь доработка фильтра в компоненте Экспорт разработки, можно отфильтровать список компонент по заблокировавшим и примечанию к блокировке). При этом блокировка с измененных компонент не снимается. Почему не стоит снимать блокировку сразу после переноса в тестовую базу? Вот пример реальной ситуации:
   • Я перенес разработку в тестовую базу, тестировщик начинает тестировать. Ему на это нужно 2 дня.
   • В течении этих двух дней, другой разработчик начинает вносить свои модификации в эту компоненту.
   • Через день тестирования, тестировщик возвращает вам доработку с кучей замечаний.
   • В результате получается, что кто-то из разработчиков должен либо откатывать свои изменения, либо на тестирование должна передаваться совокупность исправлений обоих разработчиков. А это приводит к сдвигу сроков и неразберихе, повышается вероятность ошибок в коде.
7. Тестировщик выполняет тестирование.
8. Изменения переносятся в продуктив.
9. В базе разработки снимаются блокировки с перенесенных компонент. Найти все компоненты, с которых нужно снять блокировку, можно при помощи новых компонент «Все блокировки элементов разработки» и «Мои блокировки элементов разработки» и фильтрации по установленным примечаниям в блокировках.

Такой порядок работы поможет как минимум от тех неприятных казусов, которые я перечислил.