Моделирование производственных процессов — это очень сложная и кропотливая работа: нужно собирать, анализировать и обрабатывать множество данных по различным отделам и производственным цепочкам. В статье я расскажу вам о моделировании процесса производства программных продуктов на примере компании Positive Technologies, где я работаю. Тема достаточно сложная и обширная, тем не менее я попытаюсь доступным языком объяснить, из каких крупных этапов состоит разработка и представлю так называемую технологическую карту производственных процессов. Надеюсь, что после этого рассказа у вас сформируется достаточно общее представление о производстве программных продуктов и о роли DevOps в обеспечении непрерывной работы конвейера по производству и доставке продуктов заказчикам.
Статья может быть полезна продуктовым менеджерам, руководителям команд и отделов, а также всем, кому интересно как устроен типовой процесс разработки программных продуктов, как выглядит технологическая карта и основные этапы Continuous Integration и Continuous Delivery.
Вы узнаете: из каких крупных этапов состоит разработка и доставка, какими сервисами и ресурсами они обеспечены, как разграничены зоны ответственности между DevOps и командами. В дальнейшем это поможет координировать свои работы и говорить на одном языке, совместно планировать этапы внедрения автоматизации, а также оценивать трудозатраты и ресурсы на внедрение, как человеческие, так и железные.
План
- Введение.
- Типовые производственные задачи.
- Упрощённая схема разработки.
- Функциональная IDEF0-модель типового производственного процесса.
- Технологическая карта производственного процесса.
- Итоги.
Введение
Ранее я уже рассказывал, чем занимается отдел DevOps в нашей компании и как происходит работа внутри отдела. Коротко отмечу, что понятие DevOps включает в себя инструменты и сервисы разработки, а также методологии и лучшие практики их использования. Исходя из этого, выделю глобальную цель от внедрения идей DevOps в компании — это последовательное снижение себестоимости производства и сопровождения продуктов в количественных показателях (человеко-часах или hardware-ресурсах vCPU, RAM, HDD, SSD). Самый простой и очевидный способ снижения общей себестоимости разработки на уровне всей компании — это минимизация стоимости выполнения типовых серийных задач на всех этапах технологического процесса производства. Но что это за этапы, как их выделить из общего процесса, из каких шагов они состоят? Ответы на эти вопросы будут даны в рассказе.
Когда мы в отделе занялись моделированием нашего производственного процесса и описанием его этапов, то преследовали конкретную цель — донести до каждого сотрудника, участвующего в разработке продуктов нашей компании, и до руководителей проектов информацию:
- как продукты и их компоненты, начиная от коммита строчки кода внутри компании, доходят до заказчика в виде инсталляторов и обновлений,
- какими ресурсами обеспечен каждый этап производства продуктов,
- какие сервисы участвуют на каждом этапе,
- как и между кем разграничены зоны ответственности для каждого этапа,
- какие контракты существуют на входе и выходе каждого этапа.
Типовые производственные задачи
Основные направления работы отдела DevOps в нашей компании: CI, внутренняя разработка, инфраструктура, мониторинг, автоматизация workflow и разработка web-сервисов.
Мы отвечаем за весь конвейер CI/CD: начиная от сборки отдельных компонент и инсталляторов продуктов, до отправки их на тестирование и публикации обновлений. Мы разрабатываем инструменты внутренней автоматизации, в том числе опенсорс-решения. Направление инфраструктуры занимается оптимизацией эксплуатации всех ресурсов отдела, а также автоматизацией разворачивания виртуальных машин и окружения на них. Направление мониторинга обеспечивает контроль работоспособности наших сервисов 24/7, также мы предоставляем мониторинг как сервис для тестировщиков. Направление workflow предоставляет командам инструменты для управления процессами разработки и тестирования, анализа состояния кода и получения аналитики по проектам. И, наконец, направление webdev обеспечивает публикацию релизов на серверах GUS и FLUS, а также лицензирование продуктов при помощи сервиса LicenseLab. Для поддержки всей производственной цепочки мы настраиваем и сопровождаем множество различных вспомогательных сервисов для разработчиков (про наши сервисы можно послушать на митапах: Op!DevOps! 2016 и Op!DevOps! 2017).
Совместно с ведущими направлений мы проанализировали такие задачи и смогли выделить их в отдельные категории работ или производственные этапы, этапы разбили на отдельные неделимые шаги, а из нескольких этапов складывается производственная технологическая цепочка.
Простейший пример технологической цепочки — это этапы сборки-деплоя-тестирования каждого нашего продукта внутри компании. В свою очередь, например, этап сборки состоит из множества отдельных типовых шагов: выкачивание исходников с GitLab, подготовка зависимостей и 3rd-party библиотек, юнит-тестирование и статический анализ кода, выполнение билд-сценария в GitLab CI, публикация артефактов в хранилище на Artifactory, генерация релиз-нотов через внутренний инструмент ChangelogBuilder, а со временем могут быть добавлены и другие шаги.
Множество типовых производственных цепочек образуют производственный процесс, который может быть описан либо функциональной IDEF0-моделью, либо технологической картой. О них я расскажу далее.
Упрощённая схема разработки
Про типовые задачи DevOps и наши простейшие производственные цепочки можно почитать в моих статьях на Хабре: "Личный опыт: как выглядит наша система Continuous Integration" и "Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps". Приведу только несколько примеров.
Отдельное внимание мы уделили разработке типовых проектов для системы непрерывной интеграции. Это позволило добиться унификации проектов, выделив так называемую релизную схему сборок с продвижениями.
Вот как это работает. Все проекты выглядят типовыми: они включают конфигурацию сборок, которые попадают в snapshot-репозиторий на Artifactory, после чего осуществляется их развертывание и тестирование на тестовых стендах, а затем продвижение в релизный репозиторий. Сервис Artifactory является единой точкой распространения всех артефактов сборки между командами и другими сервисами.
Если очень упростить и обобщить релизную схему, то полный производственный CI-процесс в компании включает в себя этапы:
- кросс-платформенная сборка продукта,
- деплой на тестовые стенды,
- запуск функциональных и иных тестов,
- продвижение протестированных сборок в релизные репозитории на Artifactory,
- публикация релизных сборок на серверы обновлений,
- доставка сборок и обновлений на продакшн,
- запуск инсталляции и обновления продукта.
Функциональная IDEF0-модель типового производственного процесса
Детально каждый этап производственного процесса и его обеспеченность ресурсами можно рассмотреть на функциональной IDEF0-модели. В этих моделях используется так называемая ICOM-нотация (Input-Control-Output-Mechanism) для описания того, какие ресурсы используются на каждом этапе, на основе каких правил и требований выполняется работа, что получается на выходе и какие механизмы, сервисы или люди реализуют конкретный этап. Как правило, рассматривая функциональные модели легче увидеть, декомпозировать и детализировать описание процессов.
Рассмотрим технологическую модель типового производственного процесса (далее просто — Модель) в виде функциональной IDEF0-модели. В ней отражены основные этапы CI-процесса. Каждый из этапов декомпозируется в виде последовательности шагов, но подробно на них я останавливаться не буду. Для примера рассмотрим только два верхних уровня Модели, а при желании вы можете изучить её самостоятельно, скачав .pdf-файл по ссылке.
Модель описывает замкнутый цикл разработки: начиная от коммита строчки кода разработчиками и завершая публикацией протестированных компонент и продуктов на серверах обновлений, а затем их установкой на инфраструктуре заказчиков.
На самом верхнем уровне A-0 Модели описан общий процесс разработки [Production] в компании. Как его можно интерпретировать и "прочитать" Модель?
Для получения и поставки заказчикам готовых инсталляторов, лицензий и обновлений продуктов, происходит преобразование исходных кодов согласно конфигурационным файлам и файлам манифестов. Разработка регулируется внутренними требованиями к продуктам, ТЗ и обратной связью (отзывами) от заказчиков. Для производства используются некоторые физические ресурсы сборочной инфраструктуры и всё это управляется системами CI/CD (Continuous Integration и Continuous Delivery), которые поддерживаются силами DevOps-отдела.
ICOM-элементы на схеме:
1. Входные ресурсы данного этапа:
- Source code I1 — исходные коды продуктов или тестов, которые написали программисты и сохранили в GitLab. В процессе сборки они будут преобразованы в готовые продукты или их компоненты, либо использованы для запуска тестовых сценариев.
- Config files and manifests I2 — конфигурационные файлы и манифесты, например, сборочный скрипт build-on-server.* или скрипт развёртывания на тестовых серверах deploy-on-server.*, config-файлы для GitLab CI, python requirements.txt или манифесты CrossPM.
2. Контроль и регуляторные требования:
- Internal rules and regulations C1 — внутренние правила и регламенты разработки.
- Customer requirements C2 — требования заказчиков.
3. Выходные ресурсы:
- Installators or components O1 — инсталляторы или компоненты продуктов.
- Licenses O2 — лицензии для продуктов.
- Updates O3 — обновления для продуктов.
Как правило, они все размещаются на серверах GUS, FLUS или LicenseLab системы SupplyLab, либо на Artifactory.
4. Управляющие механизмы:
- Hardware resources M1 — физические ресурсы: ESX (vSphere), сборочные пулы, утилиты DevOps-Tools, скрипты CrossBuilder, CrossPM и другие.
- CI/CD Management System M2 — системы CI/CD (GitLab CI), системы отчётности: ChangelogBuilder и TestRail.
На уровне A0 Модели проведена декомпозиция общего процесса разработки.
Стандартный для нашей компании процесс разработки [Production] представлен в виде последовательности этапов: Building — Deploying — Testing — Promoting — SupplyLab Publishing (GUS) — SupplyLab Delivering (FLUS) — Installing & Updating (SCM).
Эти этапы обобщают процессы сборки продуктов [Build], их деплоя на тестовые серверы [Deploy], тестирования [Test], продвижения сборок в релизные репозитории по итогам тестирования [Promote], общий этап публикации [Publish] на сервере обновлений GUS и доставки до серверов обновлений FLUS, а также инсталляция и обновление компонент продуктов на инфраструктуре заказчика средствами Product CM [Install].
ICOM-элементы на схеме:
1. Входные ресурсы данного этапа:
- Source code I1 — это либо исходные коды продуктов, либо тесты (юнит- или функциональные тесты, необходимые для проверки работоспособности кода продукта). В процессе сборки исходники будут преобразованы в готовые продукты или их компоненты, а код тестов будет использован для запуска тестовых сценариев. Также дополнительно может быть оценено качество кода с помощью анализатора кода SonarQube. Обычно идёт чёткое разделение по тестам: модульные юнит-тесты запускаются только на шаге сборки (там же выполняется и оценка качества кода), а функциональные и прочие тесты запускаются на шаге тестирования компоненты, после её деплоя на тестовом стенде.
- Test code — разновидность для "Source code I1": в данном случае, это исходный код авто-тестов, загружаемый и запускаемый на стороне тестовых стендов.
- Config files and manifests I2 — это либо сборочный скрипт build-on-server.* на шаге сборки, либо скрипт развёртывания продукта на тестовых серверах deploy-on-server.*, либо конфигурационные файлы для инсталляции продукта.
- Build manifest, e.g. build-on-server.* — разновидность скриптов "Config files and manifests I2": на шаге сборки это файлы сборочных скриптов build-on-server.*.
- Deploy manifest, e.g. deploy-on-server.* — разновидность скриптов "Config files and manifests I2": на шаге деплоя на тестовые стенды это файлы деплойных скриптов deploy-on-server.*.
- Installation config — разновидность скриптов "Config files and manifests I2": на шаге инсталляции продукта в качестве них используются определённые конфигурационные файлы.
2. Контроль и регуляторные требования:
- Internal rules and regulations C1 — разработчики особо не влияют на требования, поэтому в данной модели будем считать, что они получают задачи из трекеров TFS или YouTrack от многочисленных аналитиков в различных проектах.
3. Выходные ресурсы:
- Installators or components O1 — основной ресурс, получаемый в результате разработки: инсталляторы или компоненты продуктов.
- Licenses O2 — дополнительный ресурс, получаемый в результате разработки: лицензии для продуктов.
- Updates O3 — дополнительный ресурс, получаемый в результате разработки: обновления для продуктов.
Набор промежуточных выходных ресурсов, генерируемых и передаваемых между этапами:
- Build artifacts on the Snapshot repository — версионированные архивы любого типа для компонентов или продуктов, генерируемые после сборки и кратковременно хранящиеся в специальных Snapshot-репозиториях на Artifactory. Далее они используются в других, например, интеграционных сборках или при деплое. Скачать их можно напрямую из Artifactory или используя манифесты инструмента CrossPM.
- Artifacts are downloaded and deployed on the QA test stand — артефакты (архивы различного типа), загруженные на Artifactory и пригодные для скачивания через инструмент CrossPM.
- Test results in TestRail — результаты автотестов, загруженные на сервер TestRail или иную систему отчётности. Кроме TestRail результаты автототестов могут храниться в виде обычных логов в GitLab CI.
- Build artifacts from the Snapshot repository — архивы, хранящиеся в Snapshot-репозитории на Artifactory.
- Build artifacts on the Release repository — архивы компонент или продуктов, протестированные и переведённые в статус релизных. Хранятся на Artifactory в специальных Release-репозиториях.
- Artifacts are published on the GUS — это специальным образом подготовленные артефакты на стороне сервера обновлений GUS, пригодные для их скачивания через сервер доставки обновлений и лицензий FLUS.
- Artifacts received from the FLUS — артефакты, скачанные с сервера GUS на сторону сервера доставки обновлений и лицензий FLUS. После этого они становятся доступны скриптам SCM для инсталляции, обновления компонент или лицензий на стороне инфраструктуры заказчика.
- Product installed and updated — результатом отработки SCM-скриптов является установленный на стороне заказчика продукт, или его обновлённые компоненты, или обновлённая лицензия на продукт.
4. Управляющие механизмы:
- Hardware resources M1 — общее понятие для физических ресурсов, которыми могут быть: ESX (vSphere), пулы сборочных серверов, утилиты DevOps-Tools, скрипты CrossBuilder, CrossPM и другие.
- CI/CD Management System M2 — общее понятие управляющих систем CI/CD, которыми могут быть: GitLab CI, системы отчётности ChangelogBuilder и TestRail, хранилище исходных кодов GitLab или бинарных ресурсов Artifactory (они оба имеют свою систему контроля и управления ресурсами), система управления пакетами CrossPM, система управления доставкой продуктов и лицензий SupplyLab (включающая GUS, FLUS и LicenseLab), скрипты для Product CM (управляющие инсталляцией продуктов) и другие сервисы, предоставляемые DevOps-отделом.
Нужно понимать, что описание всего производственного процесса достаточно трудно вместить в одну функциональную модель. Причина в сложностях, которые возникают с ростом числа её элементов. Поэтому далее она будет преобразована и представлена в виде так называемой технологической карты.
Технологическая карта производственного процесса
В Модели были отражены лишь основные этапы производственного процесса, относящиеся, в основном, к сборке продуктов. Но в разработке есть и вспомогательные этапы: мониторинг, сертификации, автоматизация воркфлоу и многие другие. Если взять все этапы и шаги из IDEF0-модели, закодировать их тегами и развернуть в одну непрерывную производственную цепочку, то она получится очень длинной и непонятной. Для примера полная производственная цепочка в нашей компании будет выглядеть так:
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]
Это этапы сборки продуктов [Build], их деплоя на тестовые серверы [Deploy], тестирования [Test], продвижения сборок в релизные репозитории по итогам тестирования [Promote], генерации и публикации лицензий [License], публикации [Publish] на сервере обновлений GUS и доставки до серверов обновлений FLUS, инсталляции и обновления компонент продуктов на инфраструктуре заказчика средствами Product CM [Install], а также сбор телеметрии [Telemetry] с установленных продуктов.
Кроме них, можно выделить отдельные этапы мониторинга состояния инфраструктуры [InfMonitoring], управления версиями исходного кода [SourceCodeControl], подготовки сборочного окружения [Prepare], управления проектами [Workflow], обеспечения команд средствами коммуникации [Communication], сертификации продуктов [Certification] и обеспечения самодостаточности CI-процессов [CISelfSufficiency] (например, независимость сборок от Интернет). И, наконец, кроме этапов есть десятки шагов, которые я даже не буду рассматривать, потому что они очень специфичные.
Будет гораздо легче понять и окинуть взглядом весь производственный процесс, если представить его в виде технологической карты — это таблица, в которую по строкам записаны отдельные производственные этапы и декомпозированные шаги Модели, а по столбцам — описание того, что делается на каждом этапе или шаге, используемые для этого ресурсы и зоны ответственности.
Определение
Технологическая карта типового производственного процесса (далее просто — карта или технологическая карта) — это табличное представление этапов и шагов производственного процесса, в котором основной акцент сделан на ресурсах, обеспечивающих каждый этап, и разграничении зон ответственности. Также карта является своеобразным классификатором ресурсов. Она отображает уже реализованные или планируемые к внедрению крупные технологические части производства продуктов. Используя её командам DevOps и Dev гораздо легче взаимодействовать и совместно планировать этапы внедрения автоматизации крупными кусками, а также понимать, какие трудозатраты и ресурсы (человеческие и железные) для этого потребуются. Внутри нашей компании карта генерируется и автоматически обновляется при помощи служебного инструмента ModelGenerator (в виде обычного .html-файла), а затем выкладывается на сервер GitLab Pages.
Упрощённо: технологическая карта — это другая интерпретация функциональной IDEF0-Модели в виде таблицы этапов и шагов.
Структура карты
Карта состоит из нескольких частей:
- Область заголовков — здесь находится общее описание карты, вводятся базовые понятия, определяются основные ресурсы и результаты производственного процесса.
- Информационная панель — здесь можно управлять отображением данных по отдельным продуктам, приводится сводка по реализованным этапам и шагам в целом по всем продуктам.
- Технологическая карта — табличное описание технологического процесса. На карте:
- приведены все этапы, шаги и их коды;
- дано краткое и полное описания этапов;
- указаны входные ресурсы и сервисы, используемые на каждом этапе;
- указаны результаты каждого этапа и отдельного шага;
- указана зона ответственности по каждому этапу и шагу;
- определены технические ресурсы, например, HDD (SSD), RAM, vCPU и человеко-часы, необходимые для поддержки работ на данном этапе, как на текущий момент — факт, так и в будущем — план;
- для каждого продукта указано, реализованы для него технологические этапы или шаги, планируются ли они к внедрению, не актуальны или не реализованы, а также указана дата актуализации.
Принятие решений на основе технологической карты
Изучив карту, возможно предпринять некоторые действия в зависимости от роли сотрудника в компании (руководитель разработки, менеджер продукта, разработчик или тестировщик): - Понять, какие этапы отсутствуют в реальном продукте или проекте и оценить необходимость их внедрения.
- Разграничить зоны ответственности между несколькими отделами, если они работают над разными этапами.
- Договориться о контрактах на входах и выходах этапов.
- Интегрировать свой этап работ в общий процесс разработки.
- Точнее оценить потребность в ресурсах, обеспечивающих каждый из этапов.
Резюмируя всё вышесказанное
Технологическая карта — универсальна, расширяема и легко поддерживаема. Разрабатывать и сопровождать описание процессов в таком виде гораздо легче, чем в строгой и академичной IDEF0-модели. Кроме того, табличное описание часто более просто, привычно и структурировано, чем функциональная модель.
Технологическая карта неформально (в отличие от формальной IDEF0-модели) описывает этапы и шаги производственного процесса. За их техническую реализацию отвечает специальный внутренний инструмент CrossBuilder — инструмент-"прослойка" между CI-системами, сервисами и инфраструктурой компании. Разработчику не нужно думать, как как реализовать тот или иной шаг, описанный на Карте — если он ему нужен, то в CI-системе достаточно запустить один из скриптов (так называемый "task") инструмента CrossBuilder, который правильно его исполнит с учётом особенностей нашей инфраструктуры. А руководителю не нужно выдумывать свой процесс разработки и что ему требуется сделать, чтобы получить готовый продукт — достаточно выбрать нужные этапы на Карте и поставить соответствующие задачи разработчикам и DevOps-команде.
После проведённой классификации и детализации этапов разработки, стало возможным провести анализ всех продуктов нашей компании и найти их несоответствие с Технологической картой. Карта помогла оптимизировать и ускорить процессы разработки за счёт понимания общего глобального процесса. Самое главное: теперь стало возможным совместно планировать поэтапное внедрение автоматизации крупными технологическими кусками и понимать трудозатраты и ресурсы на это.
Итоги
- Цель внедрения идей DevOps — последовательное снижение себестоимости производства и сопровождения продуктов компании в количественных показателях (человеко-часах или hardware-ресурсах vCPU, RAM, HDD, SSD).
- Способ снижения общей себестоимости разработки — минимизация стоимости выполнения типовых серийных задач: этапов и шагов процесса разработки.
- Типовая задача — задача, решение которой автоматизировано полностью или частично, не вызывает трудностей у исполнителей и не требует значительных объёмов работ.
- Производственный процесс состоит из этапов, этапы разбиты на неделимые шаги. Этапы и шаги представляют собой типовые задачи (разного уровня масштабов и объёмов), которые приходится решать в процессе разработки продуктов.
- От разрозненных типовых задач мы пришли к сложным технологическим цепочкам и многоуровневым моделям производственного процесса, которые могут быть описаны функциональной IDEF0-моделью или технологической картой.
- Технологическая карта — это табличное представление этапов и шагов производственного процесса. Она отображает уже реализованные или планируемые к внедрению крупные технологические части производства продуктов. Самое главное: карта позволяет увидеть весь процесс целиком, крупными кусками с возможностью их детализации.
- На основе технологической карты можно предпринимать некоторые действия: оценить необходимость внедрения этапов в реальном продукте, разграничить зоны ответственности, договориться о контрактах на входах и выходах этапов, интегрировать свою часть работ в общий процесс разработки, точнее оценить потребность в ресурсах.
