Как автоматически создать инкрементный package.xml для Salesforce?

Кто-нибудь экспериментирует с автоматическим созданием файла salesforce Package.xml для непрерывной интеграции? Если есть сценарий или идея, поделитесь.

Вы знаете, что инкрементный package.xml помогает развертывать только измененные файлы, а не использовать полный package.xml, который также повторно развертывает немодифицированные файлы, что занимает много времени.

Заранее спасибо!

2 ответа

Сложно. И это не совсем проблема, связанная с программированием, рассмотрите возможность перекрестной публикации этого на https://salesforce.stackexchange.com/ или, возможно, даже на https://devops.stackexchange.com/

Не думаю, что однозначного ответа нет, придется поэкспериментировать. Тем более, что вы отметили "инструмент миграции" (так что старая школа, проверенная в боях, но с более низким приоритетом API метаданных; похоже, что все внимание теперь сосредоточено на стиле развертывания SFDX). Используете ли вы какой-либо контроль версий (в идеале Git) или вы надеетесь каким-то образом сравнить исходную и целевую организации, выяснить дельты и развернуть только их?

Помните, что часто SF с каждым выпуском лучше обнаруживает "без изменений" (сколько лет jar-файлу вашего инструмента миграции?). Например, когда я развертываю свой текущий проект в пустой песочнице (точная копия продукта, никаких пользовательских объектов, кода и т. Д.), Первоначальное развертывание занимает ~7 минут. Но любое последующее развертывание с тем же содержанием или небольшими изменениями занимает всего 3-4 раза. Поэтому попробуйте подсчитать время, потерянное в общей схеме вещей, и решить, какие выгоды вы хотите увидеть / сколько времени вы хотите потратить на эксперименты и настройку решения.

Вы можете изучить специализированные решения для развертывания, такие как Gearset, Autorabit, Odaseva (я не связан ни с одним из них, и этот список не является исчерпывающим). Часто они могут провести за вас сравнение.

Есть несколько проектов, которые пытаются составить package.xml на основе различий Git между двумя коммитами. Конечно, сначала нужно иметь репо и какой-то режим:

  • https://github.com/cloudsandbox/sfdx-gen-pack видел презентацию об этом на Cloudforce London 2019
  • https://github.com/Accenture/sfpowerkit, похоже, имеет команду "diff" (отказ от ответственности: раньше я работал в Accenture, но теперь не связан с ним, не работал над инструментом, не использовал его лично)
  • https://cumulusci.readthedocs.io/en/latest/ this seems to be interesting and mature. Built by SF employees, not an official tool but used to CI deploy the non-profit packages they build (maybe you heard about Non Profit Starter Pack, especially if you ever considered enabling Person Accounts). I'm not sure if they do delta deployments as such but there seems to be a command that updates package.xml with files in repository so it's a start? https://cumulusci.readthedocs.io/en/latest/tutorial.html

I'm not saying CumulusCI will be a silver bullet but out of these 3 seems to be most actively maintained;) But sounds like you'd have to get familiar with SFDX (if not whole thing then at least commands to convert the project back and forth between "source" (SFDX) structure and Metadata API structure

Отвечая на свой вопрос сам: я нашел git diff master feature/vat | force-dev-tool changeset create vat за работой!

Благодаря Роману ответил в https://salesforce.stackexchange.com/questions/184332/is-there-a-pre-build-solution-for-generating-a-package-xml-from-a-git-repo

Другие вопросы по тегам