Перейти к содержимому
HPI Pro — Salesforce consulting and implementation

CI/CD и DevOps для Salesforce

Релиз перестаёт быть стрессовым событием, когда у него есть процесс.

Мы выстраиваем управляемый конвейер релизов для Salesforce: единый источник правды в Git, определённые среды, автоматические тесты, шлюзы качества и путь отката — чтобы каждое изменение попадало в продуктив предсказуемо и с полной прослеживаемостью.

Выстроить процесс релизовПроверить существующую систему

Конвейер релизов

Как изменение проходит путь от разработки до продуктива

Схема показывает конвейер целиком — от среды, в которой написано изменение, до контроля после выхода в продуктив.

Governed Release Pipeline

Источник

Где рождается изменение

  • Scratch org / sandboxИзолированная разработка
  • Метаданные в GitЕдиный источник правды
  • Ветка на задачуПрослеживается до требования

Интеграция

Что выполняется автоматически

  • Pull requestОбязательное ревью
  • Статический анализPMD и стандарты кода
  • Тесты ApexПокрытие и качество

Шлюзы качества

Что блокирует продвижение

  • Минимальное покрытиеСогласованный порог
  • Регрессионный наборКритичные сценарии
  • Согласование бизнесаЗадокументированный UAT

Релиз

Как изменение доходит до продуктива

  • Автоматический деплойТот же артефакт
  • Данные средСогласованные среды
  • Окно релизаЗапланировано и объявлено

Контроль

Что происходит после

  • Плановый откатИзвестный путь назад
  • Мониторинг и оповещенияЗаданные пороги
  • Release notesДокументация к каждой версии
Каждый этап добавляет уверенности. Закрытый шлюз останавливает изменение до продуктива, а не после.

Контекст

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

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

CI/CD для Salesforce — это не только инструменты. Это договорённость о том, что считается утверждённым изменением, кто его утверждает, какие проверки обязаны пройти и что происходит при сбое.

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

Направления работы

Что мы делаем на практике

Стратегия сред

Карта sandbox, scratch orgs и UAT под реальный темп работы команды.

Метаданные в Git

Структура репозитория, ветвление и посильная для команды политика слияния.

Автоматический конвейер

Сборка, тесты и деплой через GitHub Actions, Azure DevOps или Gearset.

Шлюзы качества

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

Данные в средах

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

Релиз и откат

Окна релизов, release notes и заранее определённый путь возврата.

Модель зрелости

Где организация находится сегодня

Большинство компаний находятся между уровнем 1 и уровнем 3. Самый значимый шаг — переход к Git как источнику правды.

1 — Ручной

Как это выглядит
Change sets и правки прямо в продуктиве
Основной риск
Нет учёта и нет возврата
Следующий шаг
Перенести метаданные в Git

2 — Частично управляемый

Как это выглядит
Git есть, но деплой выполняется вручную
Основной риск
Расхождение между средами
Следующий шаг
Автоматизировать деплой

3 — Автоматизированный

Как это выглядит
Конвейер запускается на каждый pull request
Основной риск
Слабые тесты пропускают всё
Следующий шаг
Определить реальные шлюзы качества

4 — Управляемый

Как это выглядит
Шлюзы качества блокируют продвижение
Основной риск
Релизы тормозит тяжёлый процесс
Следующий шаг
Сфокусировать регрессионный набор

5 — Непрерывный

Как это выглядит
Частые релизы с известным откатом
Основной риск
Операционная расслабленность
Следующий шаг
Мониторинг и регулярные ревью

Как мы работаем

Этапы внедрения

  1. 01

    Карта текущего состояния

    Среды, инструменты, темп релизов и реальные точки отказа.

  2. 02

    Проектирование конвейера

    Ветвление, среды и шлюзы качества под конкретную команду.

  3. 03

    Развёртывание инфраструктуры

    Репозиторий, автоматизация и первые проверки в тестовой среде.

  4. 04

    Параллельная работа

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

  5. 05

    Перевод команды

    Регламенты, права доступа и обучение по ролям.

  6. 06

    Постоянный контроль

    Измерение темпа, доли сбоев и времени восстановления.

Продолжить отсюда

Сопутствующие услуги и руководства

Часто задаваемые вопросы

Часто задаваемые вопросы

Нужна ли большая команда разработки, чтобы оправдать CI/CD?
Нет. Даже команда из двух-трёх человек получает выгоду, поскольку главная ценность — предсказуемость и прослеживаемость, а не объём. Небольшой команде просто строят более простой конвейер.
Мы работаем в основном с Flow и настройками. Это применимо?
Безусловно. Изменения конфигурации и автоматизации — такие же метаданные, и именно они часто становятся причиной релизных инцидентов. Управление ими в Git даёт полную прозрачность.
Какие инструменты вы используете?
Выбор зависит от организации. GitHub Actions или Azure DevOps подходят техническим командам, а Gearset или Copado — когда основная часть работы приходится на настройку.
Сколько времени занимает построение процесса?
Базовый конвейер запускается за несколько недель. Расширение до полных шлюзов качества и регрессионных тестов идёт постепенно, чтобы не останавливать текущую разработку.

Следующий шаг

Выстроить процесс релизов

Мы разберём, как сегодня устроены ваши среды и релизы, и определим конвейер под ваш темп работы.

Шаг 1 из 2

Ваши данные будут использованы исключительно для связи с вами в соответствии с политикой конфиденциальности.

Следующий шаг

Выстроить процесс релизов

Мы разберём, как сегодня устроены ваши среды и релизы, и определим конвейер под ваш темп работы.

Выстроить процесс релизовПроверить существующую систему