Всем привет. Я бы хотел поделиться своим опытом использования Scratch orgs (дальше - SO) на реальном проекте. На данном форуме есть несколько статей по основам SO, сам SF предоставляет полнейшую документацию по этой тематике. Я же хочу поделиться опытом именно реального использования SO, пролить свет на используемый флоу.
Кроме того, имея только теоретические знания по SO, не особо внушала доверие эта штуковина. После же использования на практике — мое отношение к SO изменилось в лучшую сторону.
Итак, на проекте использовалась система контроля версий (не принципиально какая, допустим, GitHub), Visual Studio Code как IDE, SO как само SF-окружение, SF сандбокс для тестирования и, соответственно, SF Production как конечный пункт деплоя.
Если коротко, то флоу был такой:
-
Создание SO (или использование созданной ранее в пределах этого проекта). Для создания SO использовался bash-скрипт. Про него ниже расскажу чуть подробнее.
-
Имплементация нового функционала на SO
-
Добавление изменений на удаленный репозиторий (стандартный Пулл Реквест → ревью → мердж)
-
Сборка пакета (того, что с package.xml файлом)
-
Деплой пакета на SF сандбокс
-
Тестирование
-
Деплой пакета на Прод
Опускаю мелочи, типа, правка багов, и т.д. Думаю, это сейчас не принципиально, так как в статье упор именно на SO.
Скрипт для создания Scratch org
Наверное, это один из ключевых моментов при работе с SO.
Конечно, можно просто в одну sfdx-команду создать оргу, но в дальнейшем это будет заметно увеличивать время разработки/настройки/деплоя.
В проекте был создан специальный bash-скрипт. Весь его описывать не буду, так как там выполняется много специфичных команд, упомяну основные:
- Создание SO:
Тут:
$orgAlias - алиас нашей орги;
$devhubAlias - алиас нашего дев хаба, на основании которого создается SO;
$durationDays - время жизни орги (максимум: 30 дней).
Все эти параметры задаются при запуске скрипта:
bash createDevOrg.bash ScratchOrgAlias DevHubAlias 30
Для конфигурации используется project-scratch-def.json файл. Этот файл тоже может дополнительно настраиваться. Например, можно специфицировать, какие дополнительные функционалы будут в нашей создаваемой SO:
-
Установка дополнительных пакетов:
-
Деплой всей метадаты на нашу созданную SO:
То есть, создавая новую SO, вся текущая метадата будет на нее залита (само собой разумеется, что git pull делается перед каждым деплоем)
Сборка и деплой пакета
Тоже немаловажный этап. С помощью sfdx все делается буквально в несколько строк.
-
Сборка пакета:
package.xml sfdx force:source:convert -d convertedMetadata -n “PackageName” -
Валидация пакета:
sfdx force:source:deploy -u SandboxAlias -x ./convertedMetadata/package.xml -c
Чисто проверка целосности пакета, без тестов. Если надо провалидировать стестами (чтобы потом можно было сделать Quick Deploy):
sfdx force:source:deploy -u SandboxAlias -x ./convertedMetadata/package.xml -c --testlevel RunSpecifiedTests -r TestClass1,TestClass2
- Деплой пакета:
Та же команда, что и во втором пункте, но без -c флажка.
Итог
Как итог могу сказать, что SO оказалась очень гибкой, простой в настраивании и использовании штуковиной. А если ваш проект ограничен с доступными сандбоксами, то, возможно, даже незаменимой.
Спасибо за внимание.