Оперативное совершенство - схемы DevOps
Узнайте больше о оперативном совершенстве → Практика DevOps
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Настройка управления версиями | ✅ Все метаданные, сохраненные в исходном формате Git посредством структуры проекта Salesforce DX с .forceignore, настроенным на исключение неактуальных файлов; все участники рабочей группы клонируют из центрального хранилища |
| Использование стартовой организации | ✅ Разработчики создают эфемерные стартовые организации из источника для работы с функциями, обязуются вернуть изменения в управление версиями и отменяют стартовые организации после завершения функций |
| Сообщения-обязательства | ✅ Каждое обязательство содержит четкое, сжатое сообщение, объясняющее, что изменилось и почему; сообщения следуют правилам рабочей группы (например, “feat:”, “fix:”, “docs:“) |
| Отслеживание изменений | ✅ Каждое изменение метаданных, собранное в управлении версиями с удостоверением автора, отметкой времени и отличием, отображающим точные изменения |
| Процесс проверки кода | ✅ Все изменения, связанные с производством, проходят через запросы на извлечение, требующие утверждения проверки перед объединением; декларативная конфигурация получает такую же проверку, как и код |
| Процедуры отката | ✅ Предыдущие версии, восстанавливаемые из журнала Git посредством операций Checkout или revert; рабочая группа задокументировала процедуры отката, протестированные в непроизводственных |
| Контрольный журнал | ✅ Полный журнал изменений сохранен в контроле версий, поддерживающем требования соответствия и расследования безопасности |
| Стратегия ответвления | ✅ Последовательная модель ответвления Git (GitFlow, GitHub Flow или на основе транка), соответствующая размеру рабочей группы и частоте выпуска; задокументировано и внедрено |
| Миграция из организации | ✅ Переход к разработке на основе источников завершен в начале жизненного цикла решения до закрепления привычек вокруг разработки на основе организации |
| Конфигурация .gitignore | ✅ Хранилище исключает созданные файлы, пользовательские параметры и регистрационные данные; содержит только исходные файлы, которые рабочие группы намерены версионировать |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Организация как источник истины | ⚠️ Разработка происходит непосредственно в общедоступных безопасных средах с экспортом метаданных в управление версиями, как считалось позже; организации и управление версиями расходятся, создавая сбои развертывания |
| Неадекватный .gitignore | ⚠️ Хранилище содержит созданные файлы, пользовательские параметры, большие двоичные файлы или регистрационные данные; вздутие хранилища и риски безопасности |
| Расплывчатые сообщения-обязательства | ⚠️ Такие обязательства, как «исправление ошибки» или «обновления» не предоставляют контекста для того, что изменилось и почему; препятствует аудиторским расследованиям и будущему обслуживанию |
| Крупные нечастые обязательства | ⚠️ Разработчики обязуются выполнять большие наборы изменений еженедельно, а не маленькие инкрементные обязательства несколько раз в день; трудно проверить, трудно изолировать ошибки |
| Обязательство напрямую перед главной | ⚠️ Разработчики перенаправляют изменения напрямую в основную/производственную ветку, минуя проверку и проверку; отмена качественных ворот |
| Нет стратегии ответвления | ⚠️ У рабочей группы отсутствует последовательная модель ответвления; разработчики создают произвольные имена ответвлений и схемы слияния; создает путаницу и конфликты слияния |
| Двоичные файлы в Git | ⚠️ Крупные двоичные файлы (PDF, видео, архивы), связанные с размером хранилища вздутия живота и замедлением операций клонирования |
| Подтверждение регистрационных данных | ⚠️ API-ключи, пароли, регистрационные данные интеграции или маркеры безопасности, приверженные контролю версий; создает уязвимость безопасности даже после удаления из последующих обязательств |
| Игнорирование конфликтов слияния | ⚠️ Конфликты слияния, разрешенные принятием одной стороны без анализа; потеря изменений или внедрение ошибок |
| Нет проверки обязательства | ⚠️ Рабочая группа никогда не проверяет, действительно ли принятые метаданные представляют предполагаемые изменения; ошибки формата метаданных или непреднамеренные изменения проскальзывают |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Безопасные среды разработчика | ✅ Отдельные разработчики используют безопасные среды Developer Sandbox для работы с функциями, тестирования блоков и быстрой итерации; каждый разработчик использует выделенную среду |
| Безопасные среды Developer Pro | ✅ Группы, разрабатывающие управляемые пакеты или требующие более высоких ограничений по объему хранилища, используют безопасные среды Developer Pro для совместной работы |
| Безопасные среды частичного копирования | ✅ Тестирование интеграции использует безопасные среды Partial Copy Sandbox с репрезентативными образцами данных (10 000 записей на объект), настроенными посредством шаблонов данных |
| Безопасные среды Full Copy | ✅ Тестирование производительности, этапирование наподобие производственной и проверка миграции данных используют безопасные среды Full Copy, содержащие полные производственные данные и конфигурацию |
| Элементы управления конфиденциальностью данных | ✅ Доступ к безопасной среде Full Copy ограничен ролями, требующими производственных данных; Маскировка данных Shield Platform Encryption применяется для непроизводственного использования при необходимости |
| Конфигурация конечной точки интеграции | ✅ Каждый уровень безопасной среды подключается к соответствующим конечным точкам тестирования для внешних интеграций; производственные интеграции никогда не подключаются из безопасных сред |
| Конфигурация среды | ✅ Архитектура интеграции использует типы настраиваемых метаданных или настраиваемые параметры для экстернализации URL-адресов конечной точки, регистрационных данных и флажков функций на среду |
| Автоматизация после обновления | ✅ Обновления безопасной среды запускают автоматические сценарии Salesforce CLI, восстанавливающие параметры безопасной среды, включительно с регистрационными данными интеграции, посевом тестовых данных, состояниями флагов функций и доставкой электронной почты |
| Обновление планирования | ✅ Расписание обновлений безопасной среды задокументировано и сообщено; обновления запланированы в периоды низкой активности для сведения к минимуму сбоев в работе рабочей группы |
| Шаблоны данных | ✅ Безопасные среды Partial Copy используют продуманные шаблоны данных, выбирающие представительные данные в объектах, поддерживающих целостность регистрационных данных |
| Правила наименования | ✅ Безопасные среды придерживаются четкого правила наименования, обозначающего цель, ответственного и цикл обновления (например, “dev-integration-q2”, “uat-release-2-4”) |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Безопасная среда общей разработки | ⚠️ Все разработчики работают в единой общедоступной безопасной среде, перезаписывая изменения друг друга; создает путаницу в отношении развертываемого состояния |
| Несвежие безопасные среды | ⚠️ Безопасные среды, не обновляемые месяцами, существенно отличаются от производственной конфигурации; тестирование в непрезентабельной среде приводит к сбоям развертывания |
| Отсутствие управления данными в полной копии | ⚠️ Безопасные среды Full Copy, содержащие персональные данные производственной организации, финансовые данные, данные HIPAA, доступные всей группе разработчиков без элементов управления доступом или маскировки данных |
| Производственные интеграции из безопасной среды Sandbox | ⚠️ Безопасные среды подключаются напрямую к конечным точкам интеграции производства, создавая риск тестовых транзакций, влияющих на производственные данные или внешние системы |
| Настройка вручную после обновления | ⚠️ Обновления безопасной среды требуют многочасовой ручной перенастройки параметров восстановления; накладные расходы не рекомендуют обновлять безопасные среды так часто, как это необходимо |
| Документация Sandbox отсутствует | ⚠️ В рабочей группе отсутствует документация о целях безопасной среды, расписаниях обновления, содержимом данных или процедурах доступа; разработчики определяют, какую среду использовать для этой цели |
| Тип единой среды | ⚠️ Рабочая группа использует только один тип безопасной среды (обычно Developer или Full Copy) для всех целей; упускает преимущества соответствующей стратегии безопасной среды на действие |
| Безопасная среда | ⚠️ Безопасные среды, выделенные отдельным лицам или проектам и никогда не выпускаемые, когда они больше не нужны; искусственный дефицит, несмотря на имеющиеся лицензии |
| Неадекватные тестовые данные | ⚠️ Тестовые данные в безопасных средах не представляют характеристики производственных данных (объемы, взаимосвязи, краевые случаи); тестирование в нереалистичной среде пропускает производственные проблемы |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Этап исходного обязательства | ✅ Разработчики обязуются вносить изменения в ответвления функций в Git посредством четких сообщений об обязательствах, объясняющих контекст и обоснование |
| Этап статического анализа | ✅ Анализатор кода Salesforce сканирует Apex на наличие уязвимостей безопасности (Топ-10 OWASP), антишаблонов производительности (SOQL в циклах, DML в циклах), проблем качества кода (сложность, дублирование) и рисков ограничения для управляющего; выполняется в считанные секунды, предоставляя немедленный отзыв |
| Этап тестирования единицы измерения | ✅ Тесты Apex выполняют проверку бизнес-логики и соответствия пределов управляющего в организации эфемерного скретча или выделенной безопасной среде интеграции; правильно изолированные тесты выполняются менее чем за 5 минут |
| Этап развертывания проверки | ✅ Метаданные развертываются в безопасной среде интеграции посредством Salesforce CLI с флажком – checkon для тестов развертывания только проверки без внесения изменений |
| Этап тестирования интеграции | ✅ Автоматические тесты проверяют многокомпонентные бизнес-правила, контракты внешней интеграции, потоки событий платформы и цепочки асинхронной обработки относительно общедоступной среды интеграции с управлением тестовыми данными |
| Этап сканирования безопасности | ✅ Дополнительные инструменты безопасности сканируют на наличие жестко запрограммированных регистрационных данных, уязвимых зависимостей, нарушений CRUD/FLS и нарушений политики соответствия; критические выводы разрушаются |
| Этап развертывания UAT | ✅ Изменения, передающие все автоматизированные ворота, развертываются в среде тестирования приемки пользователя для проверки бизнеса; развертывание может быть автоматическим или требовать утверждения вручную на основе риска изменений |
| Этап развертывания производства | ✅ После утверждения UAT изменения развертываются в производстве с автоматическим выполнением одним нажатием, комплексной регистрацией и возможностью немедленного отката |
| Время выполнения ожидаемых продаж | ✅ Сводные ожидаемые продажи выполняются менее чем за 15 минут для типичных изменений, обеспечивающих быструю обратную связь; более длительные для больших развертываний или обширных тестовых пакетов |
| Создание артефактов | ✅ Конвейеры сохраняют пакеты развертывания, результаты тестирования, отчеты по сканированию безопасности и журналы выполнения для соответствия и устранения неполадок |
| Инструмент для конвейеров | ✅ Рабочие группы используют Salesforce DevOps Center для нативного CI/CD платформы или интегрируются с внешними платформами (Действия GitHub, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Уведомления о сбое | ✅ Ошибки ожидаемых продаж инициируют уведомления для подтверждения автора и соответствующих каналов с контекстом диагностики, позволяющим быстро устранить |
| Защита филиала | ✅ Основные/производственные филиалы защищены, требующие прохождения проверки CI и утвержденных проверок перед объединением; прямые обязательства предотвращены |
| Продвижение окружающей среды | ✅ Изменения проходят через определенный путь рекламной акции (разработка → интеграция → UAT → производство) с проверкой на каждом этапе |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Развертывания вручную | ⚠️ Изменения, развернутые вручную посредством наборов изменений или команд Salesforce CLI с несогласованными этапами; человеческие ошибки, пропущенные этапы, отсутствие контрольного журнала |
| Нет статического анализа | ⚠️ Конвейеры пропускают анализатор кода Salesforce или аналогичные инструменты; уязвимости безопасности, антишаблоны производительности, проблемы качества кода достигают производства |
| Недостаточное тестирование | ⚠️ Ожидаемые продажи проверяют только покрытие минимум 75% без выполнения тестов интеграции или проверки ключевых потоков пользователей; регрессии проскальзывают |
| Без сканирования безопасности | ⚠️ Конвейеры никогда не проверяются на наличие жестко запрограммированных регистрационных данных, уязвимых зависимостей или нарушений CRUD/FLS; проблемы безопасности обнаружены в проверках производства или безопасности |
| Медленное выполнение ожидаемых продаж | ⚠️ Сквозные ожидаемые продажи занимают 45-60+ минут, сдерживая частые обязательства и замедляя циклы обратной связи; разработчики берут на себя обязательство реже накапливать большие изменения |
| Пропущенные ошибки ожидаемых продаж | ⚠️ Группы игнорируют или переопределяют сбои ожидаемых продаж для соблюдения сроков; качественные ворота становятся театром, а не фактическим управлением |
| Нет паритета тестовой среды | ⚠️ CI/CD проверяется в среде с другой конфигурацией, ограничениями или характеристиками данных, чем в производственной среде; прохождение проверки не гарантирует успех производственной среды |
| Отсутствует возможность отката | ⚠️ Ожидаемые продажи автоматизируют развертывание, но не предоставляют автоматического отката; восстановление после неудачного развертывания требует ручных процедур экстренной помощи |
| Нет журналов развертывания | ⚠️ Развертывания, выполняемые без комплексной регистрации; устранение неполадок или аудит развертываний затрудняется |
| Тестирование по принципу «Все или ничего» | ⚠️ Конвейеры выполняют все тесты для каждого изменения, вне зависимости от того, что изменилось; 30-минутный пакет тестов выполняется даже для обновлений документации |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Флаги функций | ✅ Изменения высокого риска развертываются с отключенными функциями за типом настраиваемых метаданных или конфигурацией настраиваемых параметров; включает тестирование в производстве без воздействия пользователя, постепенное развертывание в сегментах, тестирование A/B и мгновенный откат посредством изменения конфигурации |
| Область флага функции | ✅ Флажки функций, зарезервированные для изменений высокого риска, влияющих на важные бизнес-процессы, чувствительные к производительности операции или новые схемы интеграции; не каждой функции нужны флажки |
| Развертывания канарейки | ✅ Бизнес-критические изменения выпускаются в поднабор малых пользователей первыми (5-10% посредством наборов полномочий или фильтрации атрибутов пользователя); когорта канарейки интенсивно отслеживает 24-48 часов, измеряя уровень успеха, производительность, уровень ошибок перед расширением развертывания |
| Окна развертывания | ✅ Развертывания, запланированные в периоды низкого использования, информированные журналами использования Event Monitoring API, отображающими фактические схемы трафика; избегает пикового использования, закрытия месяца, закрытия квартала, основных бизнес-событий |
| Коммуникация развертывания | ✅ Заинтересованные лица получают предварительное уведомление об окнах развертывания, включительно с ожидаемой продолжительностью, задействованными функциями и графиком отката решений |
| Процедуры отката | ✅ Документированные и проверенные процедуры отката для каждого типа развертывания; рабочая группа может выполнить откат менее чем за 30 минут при необходимости |
| Тестирование отката | ✅ Процедуры отката, проверенные в непроизводственной среде перед значительным развертыванием, обеспечивающим возможность восстановления |
| Проверка развертывания | ✅ Тесты дыма после развертывания проверяют важные потоки пользователей, конечные точки интеграции и ключевые функции сразу после выпуска |
| Координация изменения | ✅ Скоординированная стратегия развертывания, когда изменения охватывают несколько систем или требуют синхронизированных выпусков на Salesforce и внешних платформах |
| Мониторинг во время развертывания | ✅ Расширенный мониторинг активен во время окна развертывания и периода наблюдения после развертывания (24-48 часов) на наличие всплесков ошибок, ухудшения производительности или сбоев потока пользователя |
| Сине-зеленая схема для интеграций | ✅ Внешние службы, фронтирующие Salesforce, используют сине-зеленые развертывания, поддерживающие две производственные среды, развертывание в неактивном состоянии сперва, переключение трафика после проверки |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Развертывания Большого взрыва | ⚠️ Крупные выпуски, содержащие много функций, рефакторингов и изменений, развернутых одновременно без постепенного развертывания; сбой немедленно влияет на всех пользователей |
| Развертывания в часы пик | ⚠️ Выпуски, запланированные в часы максимальной нагрузки (середина дня, конец месяца, квартал), когда использование является наивысшим, а влияние проблем на пользователей — максимальным |
| Нет плана отката | ⚠️ Развертывания выполняются без задокументированных и протестированных процедур отката; при возникновении проблем рабочая группа пытается определить восстановление |
| Переключатели как запоздалые | ⚠️ Флажки функций, добавленные реактивно при возникновении проблем, а не предназначенные для активных изменений высокого риска; ограничивает параметры отката полной отменой развертывания |
| Проверка без развертывания | ⚠️ Изменения, развернутые в производстве без тестов дыма после развертывания; рабочая группа предполагает успешное развертывание и переход; проблемы, обнаруженные пользователями спустя несколько часов |
| Непроверенные процедуры отката | ⚠️ Процедуры отката задокументированы, но никогда не тестировались в непроизводственных условиях; во время фактического инцидента процедура не выполняется или оказывается неадекватной |
| Параллельные изменения нескольких систем | ⚠️ Скоординированные изменения в Salesforce и внешних системах, развернутых без синхронизации или тестирования на совместимость; создает ошибки интеграции |
| Без расширения мониторинга | ⚠️ Развертывания выполняются без усиленного мониторинга во время окна развертывания; проблемы обнаруживаются посредством жалоб пользователей, а не активных предупреждений |
| Развертывания в выходные | ⚠️ Основные выпуски, развернутые в пятницу вечером или в выходные дни, когда покрытие вызовов сокращается, а доступность службы поддержки поставщиков ограничена |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Покрытие теста единицы | ✅ Значимое покрытие теста, проверяющее бизнес-правила, краевые обращения, пути ошибок и метод ограничения губернатора; значительно превышает минимальное требование 75% |
| Качество тестирования единицы продукции | ✅ Тесты проверяют бизнес-логику, а не функциональность платформы; хорошо написанные единичные тесты быстры (миллисекунды), изолированы (нет общего состояния) и сфокусированы (каждый тест проверяет один алгоритм) |
| Тестирование стратегии данных | ✅ Тесты используют методы @TestSetup для распространенных тестовых данных; избегайте запросов SOQL в тестах, где возможно; используйте Test.loadData() для загрузки статических ресурсов |
| Насмешка над внешними зависимостями | ✅ Единичные тесты имитируют внешние выноски посредством тестовых заглушек и впрыска зависимости, включающие быстрое выполнение без реальных запросов HTTP |
| Тесты интеграции | ✅ Проверка взаимодействий между триггерами, потоками, событиями платформы, пакетными заданиями и внешними выносками, выполняемыми в безопасных средах с помощью репрезентативных тестовых данных |
| Надежность тестирования интеграции | ✅ Тесты интеграции повторяются и детерминистские; спорадические сбои устраняются посредством механизмов синхронизации, например, кодов повтора событий платформы и пакетного опроса заданий |
| Сквозные тесты | ✅ Автоматическое тестирование обозревателя (селен, драматург, провар) проверяет полные путешествия пользователей для бизнес-критических потоков, выполняющих системные упражнения посредством пользовательского интерфейса точно по мере взаимодействия пользователей |
| Тестовый фокус E2E | ✅ Тесты E2E фокусируются на наиболее ценных путях пользователей из-за более медленного выполнения (минуты на тест) и более высокой нагрузки обслуживания от изменений пользовательского интерфейса |
| Загрузочное тестирование | ✅ Производительность, проверенная при реалистичных параллельных нагрузках пользователей и объемах данных посредством служб загрузочного тестирования Salesforce или сторонних инструментов; отображает проблемы с ограничением управляющего, споры о блокировке, ухудшение производительности |
| Частота нагрузочных испытаний | ✅ Нагрузочные тесты выполняются перед основными выпусками и периодически (ежеквартально) для проверки производительности при текущих объемах производства 3х-5х |
| Испытательная пирамида | ✅ Сбалансированное тестовое распределение: много единичных тестов (сотни, минуты), меньше тестов интеграции (десятки, минуты), мало тестов Е2Е (до 20, минуты); быстрый отзыв на базе, комплексная проверка вверху |
| Тестовая изоляция | ✅ Тесты не зависят друг от друга; могут выполняться в любом порядке; каждый тест оставляет систему в чистом состоянии или использует @TestSetup для последовательной отправной точки |
| Отрицательные сценарии тестирования | ✅ Тесты проверяют обработку ошибок, применение правил проверки, применение полномочий и изящную деградацию при неблагоприятных условиях |
| Тестирование ограничения губернатора | ✅ Тесты специально проверяют алгоритм, приближающийся к контролирующим ограничениям, включительно с ограничениями запросов SOQL, ограничениями DML, процессорным временем, размером кучи |
| Непрерывное выполнение теста | ✅ Тесты выполняются автоматически при каждом подтверждении посредством ожидаемых продаж CI/CD; неудачные тесты предотвращают развертывание в более высоких средах |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Тестирование на покрытие | ⚠️ Тесты, написанные исключительно для достижения минимального покрытия 75% без проверки бизнес-правил или краевых обращений; тесты, которые ничего не утверждают или тестируют тривиальные пути кода |
| Тестирование функций платформы | ⚠️ Тесты проверяют сохранение записей Salesforce или работу запросов SOQL вместо проверки бизнес-логики; тратят усилия на гарантии платформы |
| Без инсценировки стратегии | ⚠️ Единичные тесты выполняют фактические выноски внешних систем; тесты медленные, затрудняют доступность внешней системы и расходуют ограничения API |
| Спорадические сбои тестирования | ⚠️ Тесты проходят или не выполняются непредсказуемо на основе времени выполнения, состояния данных или порядка выполнения тестов; рабочие группы учатся игнорировать сбои и выполнять повторно до завершения тестов |
| Нет тестирования интеграции | ⚠️ Существуют только единичные тесты; рабочая группа никогда не проверяет корректность совместной работы триггеров, потоков, событий платформы и пакетных заданий |
| Только ручное тестирование E2E | ⚠️ Важнейшие потоки пользователей проверяются вручную перед каждым выпуском; автоматические тесты E2E отсутствуют; в производстве обнаружены регрессии, когда ручное тестирование пропускает сценарии |
| Без загрузочного тестирования | ⚠️ Производительность никогда не проверяется при реалистичных параллельных нагрузках; проблемы ограничения регулятора, спор о блокировке или ухудшение производительности обнаружены в производстве |
| Тестирование зависимостей данных | ⚠️ Тесты зависят от конкретных записей, существующих в организации, или предполагают определенную конфигурацию пользователя; прерываются при обновлении безопасной среды или изменении конфигурации |
| Нет отрицательных тестовых случаев | ⚠️ Тесты проверяют только сценарии счастливого пути; никогда не тестируйте обработку ошибок, принудительную проверку или проверку полномочий; режимы сбоев не обнаружены |
| Пропущенные тесты | ⚠️ Неудачные тесты комментируются из @isTest и пропускаются, а не исправляются; пакет тестов со временем ухудшается по мере игнорирования дополнительных тестов |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Проверка покрытия | ✅ Все изменения, связанные с производством, проходят проверку кода посредством запросов на извлечение, требующих утверждения перед объединением; включает Apex, Aura, LWC, потоки, правила проверки, наборы полномочий, правила общего доступа |
| Контрольный список критериев проверки | ✅ Явный контрольный список, охватывающий вопросы безопасности (применение CRUD/FLS, проверка вводных данных), производительности (пакетирование, оптимизация SOQL), соответствия регулирующим ограничениям (схемы обработки, предотвращение рекурсий), ремонтопригодности (название, документация, сложность), покрытия теста (содержательные тесты, краевые случаи), архитектурной последовательности (схемы проектирования, разделение проблем) |
| Проверка ограничений размера | ✅ Извлечение запросов, сохраненных под 400 строками значимых изменений, позволяющих провести тщательную проверку; большие функции разбиваются на более мелкие инкрементные изменения, которые могут быть проверены и независимо развернуты |
| Сроки проверки | ✅ Проверки, завершенные в течение одного рабочего дня, сохраняют динамику разработки и предоставляют быструю обратную связь; задержки с проверками создают переключение контекста над головой |
| Автоматические предварительные проверки | ✅ Статический анализ, единичные тесты и сканирование безопасности выполняются автоматически перед запросом проверки; автоматические проверки выявляют механические проблемы, поэтому проверяющие фокусируются на дизайне и бизнес-логике |
| Ответственность за распределенную проверку | ✅ Ответственность за проверку кода распределена между рабочей группой, предотвращающей узкие места и обменивающейся Knowledge; младшие разработчики просматривают старший код и объясняют собственный код во время проверок |
| Качество комментариев проверки | ✅ Эксперты предоставляют конкретные действенные отзывы с обоснованием; различают обязательные изменения (проблемы блокировки) и предложения (приятные улучшения) |
| Проверка документации | ✅ Описание запроса на извлечение объясняет, что изменилось, почему изменилось, какое тестирование было выполнено и какие-либо специальные рекомендации по развертыванию или процедуры отката |
| Проверка декларативной конфигурации | ✅ Потоки, правила проверки и изменения полномочий проходят такую же проверку, как и код; конфигурация архитектура и заслуживает тщательного изучения |
| Последующая деятельность в связи с комментариями | ✅ Все комментарии по проверке, адресованные до объединения; ответы на вопросы, внесенные изменения или обоснование причины непринятия предложения |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Нет проверки кода | ⚠️ Изменения, принятые непосредственно в производственном филиале без какой-либо коллегиальной проверки; отмена механизма обнаружения первичных дефектов |
| Штамповка резины | ⚠️ Проверяющие утверждают запросы на извлечение в течение нескольких секунд без фактического изучения изменений; проверка становится соответствием поля флажка, а не воротами качества |
| Узкое место единого рецензента | ⚠️ только один старший разработчик, уполномоченный проверять код; создает узкие места и единую точку сбоя; Knowledge сосредоточены, а не распространены |
| Запросы на массовое извлечение | ⚠️ Извлечение запросов, содержащих тысячи строк изменений, охватывающих несколько функций; невозможно тщательно рассмотреть, что приведет к поверхностному изучению |
| Отложенные проверки | ⚠️ Запросы на извлечение остаются нерассмотренными несколько дней или недель; разработчики теряют контекст и переходят на другую работу; комментарии к просмотру приходят, когда разработчик переключает ментальный контекст |
| Нет критериев проверки | ⚠️ В рабочей группе отсутствуют четкие критерии того, что проверяющие должны изучать; качество проверки дико варьируется в зависимости от проверяющего; некоторые проверяющие фокусируются на стиле, другие на логике, нет всеобъемлющих |
| Проверка без тестирования | ⚠️ Проверяющие утверждают изменения только на основе проверки кода без извлечения ответвления и локального тестирования или проверки прохождения автоматических тестов |
| Пропущенные автоматические проверки | ⚠️ Проверяющие утверждают запросы на извлечение, несмотря на неудачный статический анализ, сканирование безопасности или тесты единиц; поражение цель автоматических ворот качества |
| Культура враждебных проверок | ⚠️ Проверки становятся личной критикой или соревновательными упражнениями, а не совместным повышением качества; препятствует обучению и психологической безопасности |
| Нет декларативной проверки | ⚠️ Потоки, правила проверки, наборы полномочий и правила общего доступа развертываются без проверки во время проверки кода Apex; создает пробел в качестве декларативной конфигурации |