Инженерный DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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