6 - 2015

Организация разработки инструментария для AVEVA PDMS в ООО «ЛУКОЙЛ-Нижегородниинефтепроект»

Александр Шишкин
Руководитель проектного офиса по внедрению трехмерного моделирования ООО «ЛУКОЙЛ-Нижегородниинефтепроект»
Игорь Беседин
Ведущий инженер проектного офиса по внедрению трехмерного моделирования ООО «ЛУКОЙЛ-Нижегородниинефтепроект»

Общий обзор

В данной статье описывается опыт ООО «ЛУКОЙЛ­Нижегородниинефтепроект» по организации системы разработки инструментария для автоматизации проектирования с использованием AVEVA PDMS. Автоматизация работы с AVEVA PDMS позволяет расширить и без того большой спектр возможностей этой системы и более точно показать особенности ведения работ в нашей организации, что в совокупности позволяет существенно повысить качество проектирования и уменьшить трудозатраты на решение типовых задач.

Любое программное обеспечение (ПО), которое хотя бы немного крупнее студенческой лабораторной работы, особенно, если оно разрабатывается не одним человеком, а группой специалистов, контролировать вручную сложно. Нужно помнить, кто, что, где, когда сделал, на какой стадии жизненного цикла ПО находится и сколько задач еще необходимо решить. Пользователям AVEVA PDMS нужно постоянно заниматься рутинной работой по установке обновленного ПО, а кроме того, каким­то образом осуществлять обратную связь об использовании ПО и ошибках, которые происходят в его работе. Для решения всех этих проблем в ООО «ЛУКОЙЛ­Нижегородниинефтепроект» и была создана система управления разработкой инструментария для AVEVA PDMS.

  • Система построена на основе свободного, в основном открытого и бесплатного программного обеспечения: Git, Redmine, Microsoft SQL Server, NLog. Каждый из этих компонентов решает свою задачу, но они связаны между собой в рамках одной системы:
  • Git — система управления версиями исходного кода ПО. Хранит исходный код всех разработок на целом наборе языков программирования — AVEVA PML, C#, Powershell, batch­скрипты;
  • Redmine — система управления проектами и задачами. Позволяет спланировать дорожную карту инструментария, разделить работу на этапы, вести разработку и контролировать процесс сверху. Связана с Git и дает возможность отследить, в рамках какой задачи была реализована та или иная часть кода;
  • NLog — платформа для журналирования любых событий в разрабатываемом ПО, от отладочных выводов до критических ошибок. Автоматически накап­ливает все сообщения в хранилище: в централизованный файл или, лучше, на SQL­сервер;
  • Microsoft SQL Server — реляционная СУБД для хранения журналов работы ПО и отчетов по ним. Для работы достаточно функциональности редакции SQL Server Express. Если у вас имеется редакция Professional или лучше, то можно настроить более удобное окружение, создав отчеты об ошибках и реализовав их автоматическую рассылку и обработку.

Система управления разработкой в нашей организации представлена на рис. 1.

Рис. 1. Схема системы управления разработкой

Рис. 1. Схема системы управления разработкой

Размещение исходного кода

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

  • что поменялось в коде?
  • кто внес изменения?
  • почему он это поменял?
  • как в случае необходимости вернуться к старой версии ПО?
  • как правильно построить резервное копирование исходных кодов ПО?
  • как объединить работу нескольких человек?

Все эти проблемы решает VCS (Version Control System) — система управления версиями. В нашей организации была выбрана Git, которая не требует постоянного подключения к центральному серверу (как и наличия самого центрального сервера), поэтому каждый разработчик может вести разработку разных элементов функционала полностью локально, лишь изредка выполняя синхронизацию с главным хранилищем. Вся версионируемая и конфигурационная информация хранится в обычных файлах в виде каталога­проекта. При использовании Git можно быстро переключаться с работы над одной функциональностью на работу над другой, не теряя изменения, так как фиксация вариантов реализации производится очень быстро. В целом, Git — одна из самых производительных VCS. Все изменения в коде сопровождаются комментариями разработчика, который их внес. Главное хранилище включено в план создания резервных копий. Всё это предоставляет полный контроль над деревом исходных кодов ПО.

В разработке инструментария для AVEVA PDMS в основном используются следующие языки программирования:

  • PML — внутренний язык AVEVA PDMS, на котором реализуется весь основной функционал по обработке данных проекта;
  • C# — язык платформы .NET Framework, который позволяет решать задачи, когда возможностей PML становится недостаточно.

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

Рис. 2. Часть истории репозитория PMLLIB

Рис. 2. Часть истории репозитория PMLLIB

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

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

Рис. 3. Пример задачи на разработку

Рис. 3. Пример задачи на разработку

Пример задачи на разработку приведен на рис. 3.

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

  1. Сначала появляется идея. Идея может возникнуть у проектировщика на фоне его собственного опыта использования AVEVA PDMS. Идея может исходить от разработчика, который провел анализ функциональности и выявил места для внесения корректировок или улучшений.
  2. Идея расширяется, дополняется артефактами и превращается в новую задачу. Задача может быть заведена напрямую автором или появиться автоматически на основе данных из системы журналирования.
  3. Ответственное лицо (чаще все­го — руководитель разработки) администрирует задачу: уточняет требования и детали реализации функционала и пользовательского интерфейса, определяет ее основные параметры: важность, срок реализации, плановые трудозатраты и ответственного исполнителя, и передает в работу исполнителю.
  4. Из подготовленных задач формируются спринты — этапы разработки, включающие задачи, которые на том или ином этапе необходимо решить. Спринт, принятый в ООО «ЛУКОЙЛ­Нижегородниинефтепроект» длится неделю. Общая оценка времени всех задач спринта немного меньше размера спринта. Спринт имеет запас времени для включения в него критических по сроку выполнения задач.
  5. Исполнитель начинает работать над задачей и реализовывать функционал. Как правило, для любой существенной доработки в системе контроля версий делается отдельная ветка из основной ветки исходного кода ПО. По окончании работы исполнитель объединяет свои наработки с главной веткой, исправляет конфликты, проводит финальное тестирование и публикует свои изменения в главное хранилище (рис. 4).
  6. В отдельных случаях руководитель разработки делает инспекцию кода (code review), изменившегося в задаче (рис. 5). Если при просмотре видны проблемы дальнейшего функционирования, стилистические недочеты или неоптимальность выбора алгоритмов для решения задачи, то он может вернуть задачу на доработку, добавив к ней соответствующий комментарий.
  7. Главное хранилище автоматически производит развертывание актуальной версии ПО на пользователей AVEVA PDMS.
  8. Автор задачи проверяет новую функциональность и закрывает задачу, если она решена, или открывает ее на доработку при выявлении каких­либо проблем.

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

Рис. 4. Содержимое редакции инструментария

Рис. 4. Содержимое редакции инструментария

Развертывание готового инструментария

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

Рис. 5. Code review двух соседних версий одного файла

Рис. 5. Code review двух соседних версий одного файла

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

1.  Разработчик обновляет версию ПО в централизованном хранилище на сервере. На данный момент это производится вручную, а в ближайшей перспективе планируется внедрить сервер автоматической сборки.

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

Обратная связь

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

Рис. 6. Главный журнал работы

Рис. 6. Главный журнал работы

Обратная связь в наших инструментах построена на основе связки платформы NLog и хранилища Microsoft SQL Server. NLog интегрируется в инструменты C# стандартным способом, для подключения же NLog к инструментам PML был разработан специальный интерфейс. Любой инструмент может в процессе своей работы генерировать сообщения шести возможных уровней, которые описывают разную степень важности происходящих событий:

  • Info — обычное информационное сообщение;
  • Trace — сообщение для отслеживания алгоритма выполнения;
  • Debug — сообщения с информацией для отладки;
  • Warning — в инструменте про­изошло что­то странное;
  • Error — в работе инструмента произошла серьезная ошибка, требуется вмешательство разработчиков;
  • Fatal — самое критическое сообщение, применяется в исключительных случаях, указывает на общую аварию системы.

Сообщения автоматически собираются на SQL Server. При наличии настроенных отчетов в службе Reporting Services разработчик может просмотреть их на странице отчета (рис. 6). Дополнительно в нашей организации реализована автоматическая ежесуточная рассылка статистики по работе инструментария на основе данных из базы ошибок для всех разработчиков и администраторов AVEVA PDMS. Параллельно с этим сейчас улучшается механизм автоматического создания новой задачи на доработку при появлении в базе нового сообщения с ошибкой (уровни Error и Fatal).

Заключение

Правильный подход к организации процесса автоматизации крайне важен для построения устойчивой, быстро работающей системы проектирования и управления данными при совместной работе нескольких проектных команд. В связи с этим все участники данного процесса в ООО «ЛУКОЙЛ­Нижегородниинефтепроект ста­раются работать слаженно, качественно и с минимальным привлечением внимания к себе разработчиков, а следовательно, финальный результат удается получить гораздо быстрее.

САПР и графика 6`2015