Как командам сократить жизненный цикл разработки SaaS-приложений, не принося в жертву целостность функций и обновлений? Портал eWeek приводит советы вице-президента по маркетингу продукции DevOps-разработчика Copado Дэвида Брукса, которые помогут ответить на этот вопрос.

Под термином «DevOps» обычно подразумевают методологию ускоренной разработки ПО, которая сочетает создание программ с ИТ-операциями. Ее предназначение состоит в том, чтобы сократить жизненный цикл разработки с одновременным предоставлением функций, патчей безопасности и обновлений в тесной увязке с бизнес-задачами. На практике многие организации рассматривают DevOps как постоянный эксперимент. Разработчики довольно часто выбиваются из графика, задерживая выполнение таких процедур, как непрерывная интеграция (continuous integration, CI), непрерывная доставка (continuous delivery, CD), тестирование и др. По некоторым данным, в отведенные сроки завершаются только 34% проектов, тогда как уложиться в выделенный бюджет удается 42% проектов. Чтобы идти в ногу с ускоренным жизненным циклом разработки, до минимума снижая риски работоспособности и безопасности ПО при каждом обновлении, командам разработчиков и ИБ-командам нужно действовать сообща.

В отличие от традиционного корпоративного софта, который устанавливается онпремис, SaaS-приложения — сервисы, которые работают в облаке безостановочно, поэтому для их обновления требуются определенные наборы изменений, доставляемые при помощи CD. В публичных облаках, таких как AWS и Heroku, они доставляются конвейерным способом поэтапно. К примеру, вначале производится доставка изменений, которые выпустила команда разработчиков, затем — тестировщиков, затем проводится предпроизводственное тестирование и, наконец, развертывание. В таких платформах, как Salesforce, место этапов занимают изолированные среды, эфемерные Scratch Org (одноразовое развертывание кода и метаданных) и производственные экземпляры.

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

1. Расширенное планирование позволяет убедиться, что все флажки установлены. В настоящее время гибкое планирование является основой для разработки уровня предприятий. Прибегать к его помощи требуется в тех случаях, когда членам команды необходимо поддерживать личный контакт или когда конечный продукт требует в течение жизненного цикла регулярного обновления, мониторинга и непрерывной доставки клиенту. Что касается последнего, стоит убедиться, что пользовательские запросы правильно определены, чтобы представлять собой отдельные бизнес-иницитивы (epic).

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

2. Управление исходным кодом, особенно в общей среде разработки. Существует несколько практик создания приложений, которые оказывают влияние на CD. Во-первых, исходный код — не единственный элемент корпоративного решения. Не менее важными компонентами для создания приложений являются структура приложения, пользовательский интерфейс, права контроля доступа и статические ресурсы (значки, изображения и др.), поэтому требуется тщательно следить за ними и управлять ими. Все компоненты должны быть зарегистрированы в системе контроля версий (version control system, VCS) как единый источник достоверной информации (single source of truth, SSOT).

Во-вторых, следует следить за тем, чтобы разработчики вносили изменения в изолированной среде. При контакте с low-code-платформами, такими, к примеру, как Salesforce.com, это правило довольно часто нарушается. Нередки случаи, когда при работе в общей среде администраторы баз данных вносят изменения в несколько баз данных, что приводит к сбоям в работе облачных сервисов.

3. Реализовать автоматизацию оценки качества программных средств сложно, но нужно. Тестирование функциональности программ — одна из важнейших составляющих разработки. Чтобы облегчить эту задачу, можно воспользоваться качественным инструментом для тестирования веб-приложений — Selenium. Однако прежде, чем приступить к тестированию, следует провести ряд подготовительных работ. Чтобы команда разработчиков кодировала в одном стиле, ее необходимо снабдить инструментами статического анализа кода, таким, к примеру, как PMD, который сообщает о проблемах, обнаруженных в коде приложения. PMD включает в себя встроенные наборы правил и поддерживает возможность написания пользовательских правил. Инструменты статического анализа кода обеспечивают единый подход к кодированию команды разработчиков.

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

4. Публикуйте изменения в определенном конвейере со строгими параметрами качества. Пакетирование для CD — это захват изменений, которые могут постепенно добавляться в следующий шаговый релиз или среду. Командам разработчиков требуется выделить для каждого этапа ветку и объединить добавочные изменения в демонстрационную ветку для обнаружения и разрешения конфликтов слияния в VCS. Изменения должны быть опубликованы в определенном конвейере со строгими параметрами качества (так называемая практика Quality Gates), которая обеспечивают соблюдение порядка выпуска релизов и автоматизированную проверку. Эта практика не позволяет разработчикам обойти ключевые этапы на протяжении всего цикла разработки — например, осуществить переход от разработки к развертыванию без тестирования кода.

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

5. Автоматизируйте конфигурацию, особенно это касается прав доступа конечного пользователя. Конфигурационное тестирование должно стать частью процесса проверки. Оно относится к специальному типу тестирования, предназначенному для оценки работы ПО в случаях разнообразных конфигураций системы. Исходя из определенного вида проекта, тестирование предусматривает выполнение одной из двух целей: определение наиболее эффективной конфигурации оборудования, обеспечивающей нужные параметры производительности (проект направлен на определения профиля работы системы); проверка объекта на совместимость с указанным в спецификации оборудованием и другими программными продуктами (проект направлен на изучение условий перемещения системы от одной платформы к другой).

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

6. Мониторинг — это не только доступность и производительность сервисов. Большинство SaaS-компаний следят за доступностью и производительностью сервисов. Однако наиболее прогрессивные компании также контролируют доступ к данным, что позволяет им выявлять неправильные настройки конфигурации, а менеджерам по продукту — отслеживать использование функций конечными пользователями.