Статьи

Настройка Bamboo для интеграции с Salesforce

В моей последней статье были описаны шаги, необходимые для настройки 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="^    &lt;tabVisibilities&gt;\n        &lt;tab&gt;standard-SocialPersona&lt;/tab&gt;\n        &lt;visibility&gt;DefaultOff&lt;/visibility&gt;\n    &lt;/tabVisibilities&gt;$"
            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="^    &lt;actionOverrides&gt;\n        &lt;actionName&gt;MapHighlightAction&lt;/actionName&gt;\n        &lt;type&gt;Default&lt;/type&gt;\n    &lt;/actionOverrides&gt;$"
            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="^        &lt;members&gt;unfiled\$public&lt;/members&gt;$"
            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.  

Хорошего дня!