В моей последней статье были описаны шаги, необходимые для настройки Force IDE для Eclipse . После установки подключаемый модуль использовался для извлечения метаданных из производственной организации Salesforce . Затем извлеченный код был зарегистрирован в Atlassian Stash — репозитории на основе git .
В этой статье Altassian Bamboo , Apache Ant и Force Migration Tool будут использоваться для автоматизации развертывания в Salesforce Org с использованием кода, зарегистрированного в Stash.
Конфигурация инструмента принудительной миграции
Первым шагом является настройка инструмента принудительной миграции в Stash. Как вы помните, имя базовой папки для моего репозитория Salesforce называется sfdc. В папке sfdc я создал папку под названием «build». Поместите следующие файлы в папку сборки :
-
ant-salesforce.jar (который является основным кодом для Force Migration Tool)
-
build.properties
-
build.xml
Кроме того, чтобы выполнить удаление как часть процесса C / I, создайте папку внутри сборки под названием «unDeployCode». Поместите следующие файлы в папку unDeployCode :
-
destructiveChanges.xml
-
package.xml
Завершенная структура файла должна выглядеть так, как показано ниже:
Конфигурирование файлов
Следующим шагом является настройка некоторых файлов, созданных выше. Обратите внимание: приведенный ниже текст содержит примеры файлов, которые могут работать некорректно в вашей организации. Они предназначены для иллюстративных целей, и я, безусловно, рекомендую ознакомиться с документацией по Force Migration Tool, прежде чем воплощать эти идеи в жизнь.
build.properties
Первый файл — это файл build.properties, который должен быть настроен так, как указано ниже:
sfdc.maxPoll = 100
sfdc.pollWaitMillis = 100000
Эти значения были значениями по умолчанию, которые хорошо работали с моей конфигурацией.
build.xml
В build.xml будет сконфигурирована большая часть работы. Для этой статьи я собираюсь включить только несколько целей Ant. В противном случае эта статья станет довольно продолжительной.
<project name="Retrieve and Deploy SFDC metadata" default="deployEmptyCheckOnly" basedir=".." xmlns:sf="antlib:com.salesforce">
<taskdef uri="antlib:com.salesforce"
resource="com/salesforce/antlib.xml"
classpath="${basedir}/build/ant-salesforce.jar"/>
<property file="${basedir}/build/build.properties"/>
<property environment="env"/>
<target name="deployEmptyCheckOnly" depends="delete_unmigrateable_files">
<echo level="info">Testing the deploy</echo>
<sf:deploy
checkOnly="true"
logType="Debugonly"
username="${sfdc.username}"
password="${sfdc.password}"
serverurl="${sfdc.serverurl}"
deployRoot="${basedir}/src"
pollWaitMillis="${sfdc.pollWaitMillis}"
maxPoll="${sfdc.maxPoll}"
testLevel="NoTestRun"
allowMissingFiles="false"
autoUpdatePackage="false"
rollbackOnError="true"
ignoreWarnings="true"/>
</target>
<target name="deployCode" depends="delete_unmigrateable_files">
<echo level="info">Performing the deploy (do not run tests)</echo>
<sf:deploy
username="${sfdc.username}"
password="${sfdc.password}"
serverurl="${sfdc.serverurl}"
deployRoot="${basedir}/src"
pollWaitMillis="${sfdc.pollWaitMillis}"
maxPoll="${sfdc.maxPoll}"
allowMissingFiles="false"
autoUpdatePackage="false"
rollbackOnError="true"
ignoreWarnings="true"
testLevel="NoTestRun"
logType="Debugonly"/>
</target>
<target name="undeployCode">
<echo level="info">Undeploying code</echo>
<sf:deploy
username="${sfdc.username}"
password="${sfdc.password}"
serverurl="${sfdc.serverurl}"
maxPoll="${sfdc.maxPoll}"
rollbackOnError="true"
allowMissingFiles="false"
autoUpdatePackage="false"
ignoreWarnings="true"
logType="Debugonly"
purgeOnDelete="true"
zipFile="unDeployCode.zip"/>
</target>
<target name="remove_profile_references">
<echo level="info">Removing references that cannot be migrated from all profiles</echo>
<echo level="info"> - Social Persona</echo>
<replaceregexp
match="^ <tabVisibilities>\n <tab>standard-SocialPersona</tab>\n <visibility>DefaultOff</visibility>\n </tabVisibilities>$"
replace=""
flags="gm"
byline="false">
<fileset
dir="${basedir}/src/profiles"
includes="**/*.profile"
/>
</replaceregexp>
<echo level="info">Removing references that cannot be migrated from all objects</echo>
<echo level="info"> - MapHighlightAction</echo>
<replaceregexp
match="^ <actionOverrides>\n <actionName>MapHighlightAction</actionName>\n <type>Default</type>\n </actionOverrides>$"
replace=""
flags="gm"
byline="false">
<fileset
dir="${basedir}/src/objects"
includes="**/*.object"
/>
</replaceregexp>
<echo level="info">Cleaning up build.xml for references that cannot be migrated</echo>
<echo level="info"> - unfiled$public</echo>
<replaceregexp
match="^ <members>unfiled\$public</members>$"
replace=""
flags="gm"
byline="false">
<fileset
dir="${basedir}/src"
includes="**/*.xml"
/>
</replaceregexp>
</target>
<target name="delete_unmigrateable_files" depends="remove_profile_references">
<echo level="info">Removing files that cannot be migrated</echo>
<echo level="info"> - Applications</echo>
<delete file="${basedir}/src/applications/standard__Work.app"/>
<echo level="info"> - Layouts</echo>
<delete file="${basedir}/src/layouts/FeedItem-Feed Item Layout.layout"/>
<echo level="info"> - Settings</echo>
<delete file="${basedir}/src/settings/PersonalJourney.settings"/>
<echo level="info"> - Workflows</echo>
<delete file="${basedir}/src/workflows/ExternalEventMapping.workflow"/>
</target>
</project>
В build.xml выше были созданы стандартные Ant-проект, определение задачи и теги свойств. Есть также четыре цели, которые отмечены следующим образом:
-
deloyEmptyCheckOnly — используется для проверки работоспособности проверяемого кода. Это зависит от «delete_unmigrateable_files», который описан ниже.
-
deployCode — используется для развертывания кода в организации Salesforce. Это зависит от «delete_unmigrateable_files», который описан ниже. На это будет ссылаться в моей следующей статье.
-
undeployCode — используется для отмены развертывания кода из организации Salesforce. Поскольку нет способа отменить изменения, успешно развернутые, этот файл пригодится для автоматического удаления элементов из целевой организации. На это будет ссылаться в моей следующей статье.
-
delete_unmigrateable_files — используется для удаления файлов, которые невозможно перенести. В приведенном выше примере стандартный__Work.app удаляется из рабочего каталога, чтобы код не передавался в целевую организацию. Список этих файлов зависит от вашей среды, но в основном их можно найти с помощью поиска Google и попыток миграции самостоятельно. Это зависит от «remove_profile_references», которое описано ниже.
-
remove_profile_references — используется для очистки элементов из профилей. Это похоже на delete_unmigrateable_file (см. Выше) и является результатом либо поисков Google, либо проб / тестов ошибок в ваших тестовых развертываниях.
Конфигурация build.xml, безусловно, является наиболее сложным фактором при развертывании. Это связано с тем, что Salesforce не всегда предоставляет подробности о том, что можно и нельзя развертывать … или что не может существовать в самих файлах развертывания. К счастью, Apache Ant позволяет очищать или удалять файлы как часть основного процесса.
Затем файлы в папке unDeployCode будут настроены.
destructiveChanges.xml
Ниже приведен пример файла destructiveChanges.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Account.AllAccounts</members>
<members>Account.NewThisWeek</members>
<name>ListView</name>
</types>
<types>
<members>Account.Classification__c</members>
<name>CustomField</name>
</types>
<types>
<members>ConversionPageController</members>
<members>testConversionPageController</members>
<members>ImportUtils</members>
<name>ApexClass</name>
</types>
<types>
<members>Conversion_Page</members>
<name>ApexPage</name>
</types>
<types>
<members>TriggerWeNoLongerNeed</members>
<name>ApexTrigger</name>
</types>
<types>
<members>Business Design Manager</members>
<name>Profile</name>
</types>
<types>
<members>CampaignMember-Campaign Member Page Layout</members>
<name>Layout</name>
</types>
<types>
<members>unfiled$public/ContactFollowUpSAMPLE</members>
<members>unfiled$public/LeadsNewassignmentnotificationSAMPLE</members>
<members>unfiled$public/LeadsWebtoLeademailresponseSAMPLE</members>
<members>unfiled$public/SUPPORTCaseResponsewithSolutionSAMPLE</members>
<members>unfiled$public/SUPPORTCaseescalationnotificationSAMPLE</members>
<members>unfiled$public/SUPPORTNewassignmentnotificationSAMPLE</members>
<members>unfiled$public/SUPPORTWebtoCaseemailresponseSAMPLE</members>
<name>EmailTemplate</name>
</types>
<version>34.0</version>
</Package>
В файле destructiveChanges.xml удаляются следующие элементы:
-
два списка в разделе «Аккаунт»
-
настраиваемое поле из объекта Account
-
два класса из нашего конверсионного проекта
-
одна страница Apex из нашего конверсионного проекта
-
один триггер
-
один профиль
-
один макет
-
несколько одинаковых шаблонов электронной почты
Хотя можно вручную удалять элементы из ваших организаций, у вас может не быть такой возможности в производственном экземпляре. Кроме того, элементы, являющиеся частью дизайна по умолчанию Salesforce (например, шаблоны электронной почты), могут вернуться в ваши организации — что может вызвать проблемы, если они попадут в Production.
package.xml
Наконец, образец package.xml показан ниже:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<version>34.0</version>
</Package>
Поскольку это в основном пустой файл package.xml, я не видел необходимости изменять этот файл … кроме атрибута версии.
После завершения настройки файлов выше, перечисленные выше файлы должны быть зарегистрированы в Stash. После регистрации и слияния вы должны увидеть свои файлы в своей ветке.
Создание процесса сборки
Atlassian Bamboo выполнит оставшиеся этапы непрерывной интеграции с Salesforce.
Настройка глобальных переменных
Хотя это и не обязательно, я рекомендую использовать глобальные переменные в Bamboo, чтобы избежать жесткого кодирования ссылок в процессе развертывания. Для каждой целевой организации должны быть созданы следующие глобальные переменные:
-
имя пользователя (sfdc.sandbox_name.username)
-
пароль (sfdc.sandbox_name.password)
-
знак безопасности (sfdc.sandbox_name.securitytoken)
-
serverurl (sfdc.sandbox_name.serverurl)
В оставшейся части моих примеров я буду использовать dev01 Salesforce org. В результате мои глобальные переменные будут выглядеть так, как показано ниже:
Создание проекта и плана
Затем в Bamboo был создан новый проект под названием Salesforce. Следуя нашим корпоративным стандартам, был создан новый план под названием «Развитие» в рамках проекта Salesforce. План имеет следующую информацию:
Другие элементы плана
Прежде чем мы перейдем к этапам плана, мы должны убедиться, что установлены следующие пункты:
-
Репозитории — должны включать репозиторий Stash, который включает в себя исходный код Salesforce
-
Триггеры — должно быть установлено в Stash Repository Triggered для автоматического запуска процесса
Создание этапов
Далее нам нужно создать этапы для процесса C / I. Это где автоматизация начинает обретать форму. Ниже приведена конфигурация для этапа « Выполнить тесты» :
Вкладка «Требования» должна содержать Ant и JDK (который мы используем 1.8).
Задачи определены как показано ниже:
Проверка исходного кода — это стандартная задача, которая извлекает код из целевой ветви в Stash. Задача «Сценарий» просто повторяет «состояние git» в журналах. Суть этого процесса находится в задаче Ant, которая имеет следующие атрибуты:
-
Описание = Вызвать deployEmptyCheckOnly (только запускать тесты)
-
Исполняемый файл = Муравей
-
Файл сборки = build.xml
-
Target = deployEmptyCheckOnly -Dsfdc.username = $ {bamboo.sfdc.dev01.username} -Dsfdc.password = $ {bamboo.sfdc.dev01.password} $ {bamboo.sfdc.dev01.securitytoken} -Dsfdc.serverurl = $ { bamboo.sfdc.dev01.serverurl}
-
Сборка JDK = Java 1.8
-
Рабочий подкаталог = build
Этап запустит задачу «depoloyEmptyCheckOnly» в файле build.xml с помощью Apache Ant. Вместо того, чтобы полагаться на значения в жестком кодировании, глобальные переменные будут заменены соответственно.
При правильном вызове и завершении экран отобразится, как показано ниже:
Что дальше?
В этой статье приведены инструкции, необходимые для загрузки файлов Force Migration Tool в репозиторий Stash. Новый проект и план были созданы в Bamboo, причем этап (называемый «Выполнить тесты») запускается автоматически при регистрации изменений.
В следующей статье будет рассказано, как можно создать кандидата на выпуск. Этот кандидат на выпуск становится снимком базы кода, которую можно отправить в любую настроенную организацию Salesforce.
Хорошего дня!