Поезд релизов Salesforce: практический подход к управлению релизами

Управление выпуском, как следует из названия, представляет собой процесс управления, планирования, планирования и контроля сборки программного обеспечения на различных этапах и в разных средах; включая тестирование и развертывание версий программного обеспечения (Humble & Farley, 2011).

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

Но что такое выпускной поезд?

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

Поезд выпуска можно условно разделить на три сегмента:

• Управление метаданными
• Непрерывная интеграция
• Управление песочницей

Управление метаданными

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

API метаданных — лучший способ управления настройками в Salesforce. Он поддерживает методы create , read , update и delete . Вы можете использовать наборы изменений, IDE Force.com и инструмент миграции Ant для переноса метаданных из одной организации в другую, поскольку все они обеспечивают миграцию через API.

Каждый инструмент имеет свои преимущества, и при выборе нужно учитывать несколько моментов:

Таблица 1: Сравнение инструментов для переноса метаданных

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

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

Это был бы хороший общий список столбцов, которые можно использовать для отслеживания этих изменений в электронной таблице:

• Название компонента
• Тип компонента
• Изменить владельца
• Описание функционала
• Отображение возможностей
• Зависимость от других компонентов
• Имя рецензента/рецензента
• URL-адрес
• Название/идентификатор организации
• Другие комментарии

Контроль версий и непрерывная интеграция

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

Контроль версий является абсолютной необходимостью для любой организации. Это позволяет разработчикам работать совместно, эффективно и безопасно. Управление разработкой и миграцией кода с несколькими разработчиками, несколькими изолированными программными средами — сложная задача в Salesforce. У Salesforce также есть собственный график выпуска и обслуживания. Эти обновления предоставляют новые функции, но они могут внести изменения в API метаданных, которые могут нарушить работу вашей сборки CI. Таким образом, помимо ситуаций, когда разработчики перезаписывают изменения друг друга, контроль версий помогает вам выстроить стратегию отката. Наличие стратегии отката является обязательным, когда ваше приложение работает на Force.com.

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

1. Разработчик проверял свои изменения в системе контроля версий.
2. CI Server/Jenkins развернет последнюю сборку в песочнице CI и запустит тестовые классы.
3. Если развертывание на шаге 2 прошло успешно, изменения объединяются в ветку QA.
4. Затем CI развернул бы последнюю фиксацию из ветки QA в песочнице QA.
5. Если QA отклоняет изменения из-за сбоев теста, шаги с 1 по 3 следует выполнять снова, пока QA не удалит изменения.
6. После того, как изменения проходят тестирование в QA, они сливаются в ветку Master.
7. Последние изменения из ветки Master развертываются в песочнице Master.

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

Управление песочницей

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

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

Ниже приведена таблица ограничений, применяемых Salesforce для различных песочниц.

Таблица 2: Сравнение пределов

Мы видим, что цена — не единственная разница между песочницами.

Песочница разработчика имеет однодневный период обновления, что делает ее пригодной для разработки, но она может вместить только 200 МБ данных и не содержит рабочих данных. В противоположность этому, песочницы с полным копированием имеют точную копию производственных данных; даже идентификаторы записей совпадают. Это может сделать его отличным для тестирования и подготовки, но период обновления в 29 дней затрудняет получение последних рабочих метаданных и данных в изолированной программной среде полной копии.

Приведенная ниже таблица служит эмпирическим правилом для выбора песочниц:

Таблица 3. Варианты использования для выбора песочницы

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

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

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

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

Этот процесс помогает нам убедиться, что изменения проходят через несколько раундов тестирования и пар глаз. У него есть серьезный недостаток: требуется много времени для разработки, тестирования и развертывания изменений.

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

Как упоминалось ранее, «песочница» — это почти точная копия производственных метаданных, но не полностью. Существует официальный список компонентов/функций, которые отключены в песочнице.

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

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

Что следует учитывать при развертывании

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

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

Мы оставим вам некоторые дополнительные моменты, которые было бы полезно иметь в виду во время вашего следующего развертывания:

1. За один раз можно развернуть только 10 000 файлов или ZIP-файл размером 39 МБ. Естественно, если полезная нагрузка слишком велика, вам придется разделить пакет на несколько частей, а затем выполнить развертывание.
2. Если развертывание завершается со сбоем из-за ошибки времени request timeout , попробуйте удалить объекты, настраиваемые поля и профили из пакета. Эти компоненты требуют больше времени для развертывания.
3. Если изменился тип поля или произошли изменения в иерархии ролей, возможны длительные задержки из-за пересчета данных, требующие некоторого времени для завершения.
4. Salesforce блокирует любой компонент, который в данный момент используется пользователем в системе. Если мы попытаемся развернуть в этом случае, развертывание завершится ошибкой.

Надеемся, что этот обзор поможет вам при следующем выпуске Salesforce.

Источники