Построение журнала событий процесса поставки ПО 15.04.2020 16:18Организация ведения журнала событий процесса поставки ПО (Software Chain of Custody) , который затрагивает весь корпоративный процесс поставки ПО, начинается со стратегических целей. Большинство компаний при планировании инвестиций в программные продукты и определения их эффективности выполняют примерно следующую последовательность действий.
Входные данные и результаты этих процессов обычно разбросаны по разным местам. Руководители компании держат идеи в голове, обрисовывают общие концепции и цели на досках, менеджеры продукта рисуют дорожные карты в PowerPoint, менеджеры релизов создают планы и расписания в Excel, владельцы продукта добавляют задачи в бэклог в Jira. Журнал событий процесса поставки ПО может трансформировать эти несвязанные наборы входных и выходных данных в структурированную, связанную, отслеживаемую цепочку решений, действий и результатов.
Примечание: Инструменты Portfolio Planning и Agile Management, такие как CollabNet VersionOne представляют собой богатый источник данных для любых операций в этом процессе, ориентированном на бизнес. Захват этих данных и добавление их в ваш журнал событий процесса поставки ПО дает полную картину процесса от начала до конца, позволяя:
- отслеживать задачи по выполнению требований регулятора, не входящих в конвейер технических задач;
- лучше визуализировать и понимать поток создания ценности;
- использовать данные для приведения бэклога технических задач в соответствие стратегическим целям;
- измерять производительность DevOps команд относительно стратегических целей.
Изменчивый ландшафт инструментов DevOps
Руководство DevOps Automated Governance Reference Architecture, которое «IT Revolution» выпустила в сентябре 2019 года, изображает технический конвейер поставки ПО в следующем виде.
Технический конвейер поставки ПО
DevOps команды управляют и выполняют действия, продвигающие программные продукты в цепочке разработки и поставки: пишут новый код, добавляют его в базу кода, тестируют, упаковывают в приложения, развертывают эти приложения в среде, близкой к производственной, и производственной среде, контролируют доступность, стабильность и производительность каждого приложения. Эти действия требуют множества инструментов, которые дают возможность управления исходным кодом, непрерывной интеграции, сборки, подготовки среды эксплуатации, развертывания приложения, объединения записей журнала и мониторинга производительности.
Такое многообразие различных, часто не связанных друг с другом инструментов, несомненно, усложняет создание журнала событий процесса поставки ПО, который надежно отслеживает выполняемую работу, фиксирует и документирует, кто или какой процесс запустил выполнение работы.
От групп DevOps часто требуется вручную собирать, компилировать и сопоставлять данные между инструментами. Группам приходится это делать, чтобы выполнить требования аудиторов к отчетности. Этот трудоемкий процесс подвержен человеческим ошибкам и отвлекает разработчиков от работы по созданию ценных бизнес-приложений.
Автоматизация – ключ к масштабируемом, возобновляемому журналу событий процесса поставки ПО
Для организации журнала событий для технических процессов поставки ПО необходимо автоматизировать процесс захвата и сопоставления фактов выполнения задач в различных инструментах в цепочке DevOps. В руководстве «DevOps Automated Governance Reference Architecture» сказано:
«С увеличением степени автоматизации DevOps становится труднее собирать данные, необходимые для подтверждения соответствия требованиям безопасности и регуляторов. Компаниям нужен автоматизированный способ отслеживать сбор данных в масштабах всего процесса поставки ПО, чтобы они могли подтвердить целостность ресурсов и безопасность всех работающих приложений»
Непрерывное улучшение посредством управления потоком создания ценностиВнедрение этого типа автоматизации, а затем ее адаптация для использования на уровне компании, требует инструментов и механизмов, предполагающих повторное использование и масштабирование. Легко воспроизводимый журнал событий процесса поставки ПО гарантирует сбор фактов для контроля процесса поставки каждого релиза. Этот процесс должен масштабироваться для автоматического захвата фактов по каждому изменению приложению, и не важно, сколько инструментов задействовано и насколько сложен технический конвейер поставки.
Управление потоком создания ценности – зарождающееся направление, которое отслеживает действия по поставке ПО и предоставляет контекстуальные данные, которые требуются компаниям для анализа и непрерывного улучшения процессов непрерывной поставки ПО. Журнал событий предоставляет основу для управления потоком создания ценности (Value Stream Management), потому что помимо обеспечения целостности приложения, журнал событий дает полную картину разработки абсолютно каждого релиза от начала до конца.
Во многих компаниях лидеры DevOps используют стратегические цели для построения дорожной карты, которая помогает принимать решения о будущем программных ресурсов: какие ресурсы нужно разрабатывать, какие нужно изменить, а какие - списать. Менеджеры продуктов разбивают дорожную карту по группам проектов, объединенных одной стратегической целью, а затем преобразуют цели в практические задачи. Затем владельцы продуктов создает бэклог пользовательских историй и изменений, чтобы команды могли планировать и оценивать ежедневную рабочую нагрузку и сроки поставки ПО.
Поток создания ценности отслеживает работы по поставке ПО с целью его непрерывного улучшения.
Многие компании сегодня так работают, но им часто не хватает сквозной цепочки сбора данных, которая может помочь лидерам понять, какие текущие технические изменения действительно поддерживают стратегические цели компании. Особенно это касается тех случаев, когда конвейер поставки ПО сложный, требует много времени и затрагивает много приложений и команд. Управление потоком создания ценности на основе журнала событий предоставляет бизнесу важные данные и анализ, необходимые для поиска возможностей автоматизации, снижения вероятности сдвига сроков релиза, устранения узких мест процесса поставки ПО. Но самое главное – это то, что при таком управлении потоком создания ценности компании способны быстрее вносить изменения в разработку ПО.