Ускорьте жизненный цикл выпуска с помощью способа развертывания: часть 1 — Блог IBM

Для многих предприятий переход в облако снижает затраты на технический долг и отвечает Капвложения к операционным расходам цели. Это включает реструктуризация в microservices, подъемно-сдвиг, реплатформинг, рефакторинг, замена и многое другое. Поскольку такие практики, как DevOps, Облако родное, бессерверной и проектирование надежности объекта (SRE) Повзрослев, фокус смещается в сторону значительного уровня автоматизации, скорости, гибкости и согласованности бизнеса с ИТ (что помогает корпоративным ИТ-организациям трансформироваться в инженерные организации).

Многие предприятия изо всех сил пытаются получить реальную выгоду от своих переходов в облако и могут продолжать перерасходовать средства. Несколько Аналитики сообщили, что более 90% предприятий продолжают тратить слишком много средств на облачные технологии, часто не получая существенной прибыли.

Истинная суть ценности проявляется тогда, когда бизнес и ИТ-специалисты могут сотрудничать для быстрого создания новых возможностей, что приводит к повышению производительности разработчиков и скорости выхода на рынок. Эти цели требуют целевая операционная модель. Быстрое развертывание приложений в облаке требует не только ускорения разработки с непрерывной интеграцией, развертыванием и тестированием (CI/CD/CT). Оно также требует ускорения жизненного цикла цепочки поставок, которое включает в себя множество других групп, таких как управление рисками и соблюдением требований (GRC), управление изменениями. , операции, отказоустойчивость и надежность. Предприятия постоянно ищут способы, которые помогут продуктовым группам перейти от концепции к развертыванию быстрее, чем когда-либо.

Подход, ориентированный на автоматизацию и DevSecOps

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

• Архитектура, основанная на шаблонах, которая стандартизирует архитектуру и процесс проектирования (при этом команды имеют автономию в выборе шаблонов и технологий или совместном создании новых шаблонов).
• Шаблоны, которые касаются аспектов безопасности и соответствия требованиям, обеспечивая прослеживаемость этих требований.
• Шаблоны как код, которые помогают систематизировать множество сквозных проблем (это также способствует модели внутреннего источника зрелости шаблонов и обеспечивает возможность повторного использования).
• Действия, управляемые конвейером DevOps, которые можно использовать на протяжении всего жизненного цикла.
• Автоматическое создание конкретных данных, необходимых для проверок безопасности и соответствия требованиям.
• Проверка эксплуатационной готовности с ограниченным ручным вмешательством или без него.

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

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

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

Путь к развертыванию: Текущая точка зрения и проблемы

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

Ключевые проблемы традиционного характера SDLC:

1. Время ожидания перед разработкой составляет 4–8 недель на этапе архитектуры и проектирования, прежде чем приступить к разработке. Это вызвано:
   • Множественные проверки «первой мили» для обеспечения отсутствия негативных последствий для бизнеса, включая проблемы конфиденциальности, классификации данных, непрерывности бизнеса и соответствия нормативным требованиям (и большинство из них выполняются вручную).
   • Процессы SDLC в масштабе предприятия, которые остаются каскадными или полугибкими и требуют последовательного выполнения, несмотря на принципы гибкой разработки в циклах разработки (например, подготовка среды только после полного утверждения проекта).
   • Приложения, которые воспринимаются как «уникальные», подлежат тщательному изучению и вмешательству с ограниченными возможностями для ускорения.
   • Проблемы в институционализации архитектуры и разработки на основе шаблонов из-за отсутствия сплоченных усилий и стимулирования изменений, таких как стандартизация.
   • Культура безопасности, влияющая на скорость разработки, с соблюдением мер безопасности и рекомендаций, часто включающих ручные или полуручные процессы.
2. Время ожидания разработки для предоставления среды и интеграции инструментов CI/CD/CT из-за:
   • Ручная или полуавтоматическая подготовка среды.
   • Шаблоны (на бумаге) только в качестве предписывающего руководства.
   • Фрагментированные инструменты DevOps, требующие усилий для объединения воедино.
3. Время ожидания после разработки (последней мили) перед вводом в эксплуатацию легко может составить 6–8 недель или более из-за:
   • Ручной сбор доказательств для прохождения проверок безопасности и соответствия требованиям, выходящим за рамки стандарта SAST/SCA/DAST (например, конфигурация безопасности, средства контроля второго дня, тегирование и т. д.).
   • Ручной сбор доказательств для проверок эксплуатации и отказоустойчивости (например, поддержка облачных операций и непрерывности бизнеса).
   • Обзоры перехода на услуги для поддержки ИТ-услуг, а также управления и разрешения инцидентов.

Путь развертывания: целевое состояние.

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

В концепции целевого состояния IBM приоритет отдается безопасности и соответствию за счет интеграции проверок безопасности и проверки соответствия в конвейер CI/CD/CT, что позволяет на раннем этапе обнаруживать и устранять уязвимости. Это видение подчеркивает сотрудничество между командами разработки, эксплуатации, надежности и безопасности посредством модели общей ответственности. Он также обеспечивает непрерывный мониторинг и обратную связь для сбора информации для дальнейшего улучшения. В конечном счете, целевое состояние направлено на быструю доставку обновлений программного обеспечения и новых функций конечным пользователям, с минимальным ручным вмешательством и с высокой степенью доверия для всех заинтересованных сторон предприятия.

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

Ключевые элементы облачной модели SDLC включают в себя:

• Архитектура и дизайн, основанные на шаблонах, институционализированы во всем предприятии.
• Шаблоны, которые включают ключевые требования безопасности, соответствия, отказоустойчивости и другие политики предприятия (в виде кода).
• Проверки безопасности и соответствия требованиям, которые ускорены в виде шаблонов и используются для описания решения.
• Основная разработка, включая создание сред, конвейеров и конфигурации сервисов (которая осуществляется через корпоративный каталог разработки платформ).
• Конвейер CI/CD/CT, который выстраивает связи со всеми действиями на протяжении жизненного цикла развертывания.
• Проектирование платформ создает, настраивает и управляет платформами и сервисами со всеми корпоративными политиками (например, шифрованием), встроенными в политики платформы.
• Инструменты безопасности и соответствия требованиям (например, сканирование уязвимостей или проверки политик) и средства автоматизации, интегрированные в конвейеры или доступные для самообслуживания.
• Генерация большого количества данных (из журналов, результатов инструментов и результатов сканирования кода) для нескольких проверок без ручного вмешательства.
• Прослеживаемость от журнала невыполненной работы до примечаний к выпуску развертывания и влияния изменений.
• Вмешательства только в виде исключений.

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

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

Прочтите Часть 2: Изучение модели зрелости и подхода к реализации.