«Инженерный DevOps»‎ (EngOps) – управленческие практики построения процессов и инфраструктуры командной разработки сложных технических систем, повышающие прозрачность, автоматизацию вспомогательных рутин обеспечения качества и связности проекта.

Термин «DevOps» заимствован из мира IT-проектов, где он связан с идеологией непрерывности и глубокой связи между процессами разработки функций и их внедрения в эксплуатируемые “на бою” компьютерные приложения, зачастую облачные, высоконагруженные, критичные к сбоям.

«Инженерный DevOps» – это переосмысление 20-летних практик прозрачности и автоматизации из IT DevOps (где в центре всего код) для инженерных компаний, где программный код теперь – это тоже важная, но не единственная часть. В инженерных компаниях роль моделирования гораздо выше, а непрозрачность процессов и разрозненность инженерных групп, помноженные на недостаточность централизации и автоматизации, приводят к ощутимо бóльшим финансовым потерям в проектах и торможению развития инженерных компаний.

                           

Запрос консультации

Три столпа инженерного DevOps


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



Культура разработки. Античное, но актуальное выражение «Ex Nihilo Nihil Fit» – «Из ничего происходит ничего» в обсуждаемом контексте говорит о том, что зачастую движение вперед – это результат внешнего импульса. Серверы сами по себе ничего не дадут, нужна поэтапная трансформация правил работы, которая делается людьми. Повышение культуры прозрачности и автоматизации требует специалистов с опытом «инженерного DevOps», наделения их полномочиями стимулировать коллектив воспринимать новое, преодолевать первичное отторжение. 

Автоматизация. Исходя из нашего опыта, без автоматизаций сопротивление коллектива новой культуре разработки будет непреодолимо, а попытка преодоления «сверху» – разрушительна. Повышение качества требует огромных дополнительных трудозатрат, которых ни у одного коллектива в свободном доступе нет. На любом этапе работы инженера сложные (и монотонные) инженерные процессы автоматизируются, освобождая его ресурсы. 

Для руководителей инженерных организаций директор по инженерным разработкам ЦИТМ Экспонента делится опытом руководства и лично демонстрирует инфраструктуру EngOps. C помощью этой формы можно:

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

- Почему эта часть системы перестала работать? 

- Когда, кем или чем была сломана система? 

При работающей инфраструктуре EngOps эти ответы находятся моментально и точно. 

Можно посмотреть историю изменений, историю прохождения автоматических тестов после каждого изменения, сравнить и вывести разницу между несколькими версиями моделей, задать конкретный вопрос автору изменений или дать предложение по улучшению, откатить нежелательные изменения или без общения с коллегами понять на моделях, почему такое изменение было внесено (например, уточнение целевых ТТХ системы). 

В рамках этого этапа необходимо выполнить следующие шаги:

  • Настройка центрального репозитория 
  • Построение системной модели 
  • Создание архитектуры проекта 
  • Обучение работе с системой контроля версий
  • Организация хранения требований 
  • Обучение привязке требований к моделям 
  • Обучение отслеживанию и корректировке требований 
  • Настройка отчетов по покрытию требованиями

Тестирование моделей и кода

Когда есть готовая инфраструктура автотестов, создание автоматизированных тестовых сценариев перестает казаться лишними трудозатратами. 

  1. Тестовые сценарии запускаются автоматически на удаленном сервере по настраиваемым событиям в проекте (например, при фиксации модели в системе контроля версий) и не нужно помнить про их запуск. 
  2. Автотесты помогают узнать о проблеме сразу же, пока инженер еще погружен в решаемую задачу, а не спустя неделю, когда уже забыл почему именно так решил смоделировать подсистему. 
  3. Обычно исправлять проблему должен тот, кто ее создал, поэтому в интересах разработчика покрыть свою часть автоматическими тестами, чтобы они срабатывали на изменения, вносимые другими инженерами, и давали другим сигнал о необходимости исправления вносимых ими изменений. 
  4. Когда есть инфраструктура автотестов, то и руководство выделяет время на создание тестовых сценариев, а это снижает уровень стресса при сдаче этапов. 
  5. Возможность увидеть сводную информацию о метриках и «здоровье» проекта позволяет снизить потери на коммуникацию с руководством или заказчиком.

Работы в рамках этого этапа:

  • Обучение инструментам тестирования 
  • Помощь в создании тестовых сценариев 
  • Привязка тестов к требованиям 
  • Настройка отчетов о тестировании
Программное обеспечение

Сервер централизации

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

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

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

Автоматизация процессов

Инфраструктура «инженерного DevOps» позволяет поручить рутину роботам, и это не только автоматизация тестирования (хотя и это очень много), но и создание (обновление) отчетов и документации, автоматическая генерация исходных кодов, сборка проектов, уведомления по событиям в проекте и так далее. 

Пример из нашей рабочей практики.

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

Мы увидели существенную выгоду от переноса инженерных рутин на сервер генерации и сборки кода. Там была создана очередь генерации прошивок с возможностью запуска нескольких параллельных процессов. За ночь создавались прошивки, а утром инженер подключал стенд и прогонял автоматические тесты. Это сильно ускорило выявление проблем, которые можно отловить только в железе. 

Месяцы отладки превратились в дни.

Способы сокращения времени разработки:

  • Настройка автоматического непрерывного тестирования, проверок, генерации отчетов на сервере 
  • Настройка автоматической генерации кода и сборки прошивок
  • Обучение инструментам проверки на ошибки 
  • Настройка отчетов о моделировании

Дорожная карта

"Под лежачий камень вода не течёт." 

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

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

Процесс трансформации культуры и передачи компетенций в зависимости от размера коллектива и разнообразия проектов варьируется по нашему опыту от 9 месяцев до 2-3 лет. 

Мы готовы пройти эти этапы вместе с Вашей командой.