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

11 14

Введение

В данной статье я хочу рассказать о том, как можно использовать одно из новшеств версии 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. В базе разработки снимаются блокировки с перенесенных компонент. Найти все компоненты, с которых нужно снять блокировку, можно при помощи новых компонент «Все блокировки элементов разработки» и «Мои блокировки элементов разработки» и фильтрации по установленным примечаниям в блокировках.

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

Алексей Язынин
Отправляем на рецензию. Тут есть два варианта, либо мы сами меняем блокировку на имя рецензента, либо рецензент обладает привилегией «Управление блокировками элементов разработки» и сам меняет ее на свое имя.

ИМХО, удобнее когда блокировка остается на разработчике. Непонятно когда рецензент доберется до данной доработки, а у разработчика могут возникнуть идеи как ее улучшить и он не сможет этого сделать, если блокировка уже не на нем.

Михаил Босомыкин
ИМХО, удобнее когда блокировка остается на разработчике.

На самом деле удобнее когда блокировка остается на компоненте до тех пор пока она не будет перенесена на продуктивный сервер. Жаль, что метод по блокировке не предусматривает перечисление имен пользователей которые могут редактировать компонент(например, разработчик, рецензент). Андрей, отличная статья, как раз искал именно описание методов и объектов блокировки.
Ксения Иванова

DevelopmentComponentLockEnabled

название установки без S, я замечание к справке оформляла.

Андрей Дозоров
название установки без S, я замечание к справке оформляла.

Спасибо, поправил в статье.

Артем Скиву
Отправляем на рецензию. Тут есть два варианта, либо мы сами меняем блокировку на имя рецензента, либо рецензент обладает привилегией «Управление блокировками элементов разработки» и сам меняет ее на свое имя. Рецензент выполняет рецензию, меняет блокировку обратно на имя разработчика.

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

 

Владислав Живонос

[q] В первом случаи формируется задача для разработчика в которой указываются все замечания. Во втором уведомление о принятии разработки рецензентом... [/q]

Учитывая сколько в системе разрабоки формируется "мусорных"-отладочных задачь разработчику надо отправлять не задачу и не уведомление, а письмо в почту.  Через почту вести диалог между разработчиком и рецензентом более удобно.

Степан Мурашов

Владислав, мне кажется, что лучше поделить тестовую и продуктивную систему.
Тогда можно будет сделать так, что разработчик будет вести разработку в тестовой, а рецензент будет работать через продуктивную систему. И задания/уведомления по рецензированию будут ходить в продуктивной системе, наравне с другими задачами по другим процессам. У нас примерно так и работает все.

Владислав Живонос

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

Степан Мурашов

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

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

Авторизуйтесь, чтобы написать комментарий