Рекомендации по развертыванию

Почему развитие напрямую в производстве - плохая идея

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

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

Надежный выпускной конвейер с несколькими этапами тестирования обеспечивает безупречное развертывание в производстве за счет:

• Проверка совместной работы интегрированных изменений.
• Позволяет отработать развертывание для определения проблем.
• Обязательно добавьте все необходимое в артефакт развертывания. Если вы что-то пропустили, это будет очевидно при тестировании.
• Предоставление нескольким заинтересованным лицам возможности протестировать изменения в Partial Copy или Full Sandbox (тестирование принятия пользователя).

Какие изменения можно внести непосредственно в производстве?

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

Например, можно спокойно выполнять административные задачи, например:

• Разработка шаблонов электронной почты.
• Создание или редактирование пользователей.
• Создание или редактирование наборов полномочий и профилей.

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

Охват управления изменениями и благого управления

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

Ниже указаны некоторые предлагаемые правила управления для поощрения надлежащей практики разработки.

• Сокращение потенциальных клиентов в производстве. Ограничьте администраторам доступ «Настройка приложения».
• Ограничьте полномочия на выполнение программных развертываний небольшим количеством администраторов.
• Рекомендуем тщательно подходить к внесенным изменениям посредством меню «Настройка» в производственной среде и придерживаться административных задач.

Стратегическое отношение к срокам развертывания

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

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

Придерживайтесь последовательного расписания выпуска. Например, стремитесь к выпуску через регулярные интервалы и в указанный день недели. Даже здесь, в Salesforce, мы планируем регулярные моратории на выпуск, чтобы избежать общесистемных сбоев в критические моменты. Согласованность планирования помогает с единым планированием и устанавливает ожидания с бизнес-пользователями и клиентами.

Наблюдение за зависимостями развертывания

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

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

Рекомендуем развернуть в следующем порядке:

• Объекты
• Классы Apex
• Компоненты и страницы Visualforce
• Веб-компоненты Lightning (LWC) и компоненты Aura
• Триггеры Apex и другие метаданные
• Профили и наборы полномочий
• Правила общего доступа

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

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

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

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