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

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

Стандартную восьмерку DevOps вы все видели, вот она.

Но если взять эти 8 этапов, по каждому найти подходящее ПО и постараться запустить процесс разработки, ничего не получится. Немного подумав, мы поняли, что нужно добавить. Еще два набора процессов – «Управление и коммуникации» и «Мониторинг процессов», которые находятся вне восьмерки и связаны со всеми инженерными инструментами DevOps.

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

Управление и коммуникации

1.1. Управление проектами

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

1.2. Управление ИТ-ресурсами

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

1.3. Управление требованиями

Требования к ПО живут своей жизнью: становятся неактуальными старые, появляются новые, меняются те, которые казались незыблемыми. Причем довольно часто количество требований на финальных стадиях проекта в разы отличается от того, что прописано в ТЗ. За всем этим надо следить.

1.4. Управление задачами и бэклогом

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

1.5. Управление релизами

Выпуск релиза – это не только автоматическое действие в рамках DevOps-инструмента, но полноценный процесс планирования и согласования действий всех команд, участвующих в разработке.  

1.6. Коллаборация

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

1.7. Управление артефактами процесса

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

1.8. Управление поставкой (Release Automation)

Казалось бы, поставка – это часть управления релизами, но нет. Есть значительная менеджерская работа, связанная с координацией поставки, которую лучше рассматривать как отдельную функциональность.

1.9. Управление процессами R&D

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

1.10 Управление процессами сопровождения

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

1.11. Управление знаниями 

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

1.12. Управление конфигурациями CMDB

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

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

Инженерные инструменты DevSecOps

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

2.1. Оркестрация автоматизированных операций

2.1.1. Continuous Integration (автоматизация сборки и развертывания
на среды разработки)

2.1.2. Continuous Delivery (автоматизация развертывания на тестовые среды, запуск автотестов)

2.1.3. Continuous Deployment (автоматизация развертывания на среды приемки и пром)

2.2. Управление кодом

2.2.1. Управление исходным кодом, кодом тестирования и кодом развертывания

2.2.2. Статический анализ кода

2.2.3. Получение исходного кода вендора

2.2.4. Автоматизация модульных тестов 

2.3. Выполнение автоматической сборки

2.4. Внутренние API (интерфейсы интеграционного взаимодействия)

2.4.1 Управление внутренними API

2.4.2. Документирование API

2.4.3 Автоматизация API тестирования 

2.5. Управление артефактами разработки

2.5.1. Доставка внешних библиотек

2.5.2. Хранение промежуточных артефактов сборки 

2.5.3. Получение дистрибутивов вендора

2.5.4. Хранение дистрибутивов/образов (docker registry)

2.6. Развертывание и конфигурирование

2.6.1. Развертывание и конфигурирование приложений

2.6.2. Конфигурирование БД (DDL/DML)

2.6.3. Управление хранением конфигураций ИС

2.6.4. Управление секретами

2.7.Тестирование

2.7.1. Управление тестированием

2.7.2. Управление тестовыми данными

2.7.3. Оркестрация автоматизированного тестирования

2.7.4. Автоматизация функционального тестирования

2.7.5. Автоматизация нагрузочного тестирования

2.7.6. Мониторинг нагрузки

2.8 Application Security (безопасная разработка)

2.8.1. Контроль Open Source артефактов (уязвимости в библиотеках)

2.8.2. SAST (статический анализ кода на уязвимости)

2.8.3. DAST (динамический анализ ИС на уязвимости) / IAST (интерактивный
анализ на  уязвимости)

2.8.4. BAST (контроль выполнения требований  ИБ)

2.8.5. WAF (обратная связь от Web App Firewall)

2.8.6. Контроль дистрибутивов/контейнеров

2.9. Прикладной мониторинг

2.10. AIOps (Artificial Intelligence for Operations) – ну это уже пограничная функция с управлением ИТ-инфраструктурой. Но по просьбе трудящихся мы ее включили в скоуп.

Мониторинг

Есть еще направления мониторинга, которые не попали в предыдущие пункты. Мы выделили два: 

3.1 Мониторинг процессов и инженерных практик

3.2 Интеллектуальный анализ процессов (Process Mining)

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

Итак, что у нас получилось? Довольно подробная карта функциональных задач процесса разработки ПО, которую можно использовать для оценки покрытия этих самых задач средствами автоматизации. Осталось ее выстроить в матрицу, разделив на смысловые блоки.

Функциональная архитектура платформы разработки ПО

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