Достигнув четвертой статьи в серии, которую я написал о непрерывной интеграции с Salesforce , мы наконец сосредоточимся на развертывании в Salesforce с использованием Atlassian Bamboo . Если вам нужно наверстать упущенное, ниже приведены ссылки на предыдущие три статьи:
Жизненный цикл разработки
На этом этапе жизненный цикл разработки выглядит следующим образом:
-
Разработчик использует Org-систему Salesforce для создания обновлений.
-
По окончании разработчик использует Force IDE в Eclipse для обновления с сервера , чтобы загрузить метаданные / код из Salesforce Org в репозиторий на основе git, например Atlassian Stash .
-
Разработчик проверяет код (используя команды git или Atlassian SourceTree ) и отправляет запрос на извлечение (PR) … или проверку кода.
-
Когда запрос PR будет утвержден и объединен с рабочей веткой, которую я назвал разработкой, Bamboo обнаружит это обновление и автоматически начнет процесс сборки.
-
Процесс сборки в Bamboo будет использовать Force Migration Tool и Apache Ant для вызова API метаданных Salesforce, чтобы вставить код в организацию Salesforce, посвященную процессу сборки. В рамках этого процесса будут запущены модульные тесты в Salesforce — так же, как и во время развертывания в производственной среде.
Что дальше?
Целью данной статьи будет выполнение следующих пунктов:
-
Создайте версию-кандидата в Stash, которая будет использоваться для развертывания кода в других организациях Salesforce.
-
Создайте релиз в Bamboo, который будет использоваться в качестве контейнера для отслеживания релизов во всех организациях в нашей среде.
-
Разверните действующий код в организации Salesforce.
-
Объедините код выпуска в главную ветку в Stash.
Создание кандидата на выпуск в Stash
В Bamboo создан этап под названием « Создать релиз »:
Работа будет включать в себя следующие задачи:
-
Запросите у пользователя идентификатор кандидата на выпуск, который обычно является датой нашего текущего спринта, плюс уникальный идентификатор. Значение будет храниться в переменной, например bamboo.release.name. Примером может быть 2015.12.16_006.
-
Проверка исходного кода — извлекает копию текущей ветви разработки, которая была рассмотрена и утверждена как часть процесса PR.
-
В Bamboo создается артефакт с именем Salesforce Build , который на данный момент является текущим снимком кода.
-
Выполняет серию команд git:
git remote set-url origin ssh://[email protected]/crm/sfdc.git
git pull origin
git checkout -b release/${bamboo.release.name}
git push origin release/${bamboo.release.name}
git status
Строим релиз в бамбуке
На стороне Развертывания Bamboo создается новое Развертывание, которое включает цели для каждой организации Salesforce. Пример выглядит так, как указано ниже:
Используя среду dev01 в качестве примера, существуют следующие задачи:
На высоком уровне:
-
Очистить рабочий каталог — убедитесь, что целевой каталог пуст.
-
Загрузка артефакта — сносит копию созданного выше артефакта Salesforce Build .
-
Ant — вызывает целевой объект deployCodeRunAllTests в build.xml, используя переменные Bamboo для имени пользователя, пароля, токена безопасности и URL-адреса целевого сервера.
-
(вторая) загрузка артефакта — вынимает копию артефакта unDeployCode, используемого для деструктивных изменений.
-
(второй) Ant — выполняет цель unDeployCode для выполнения деструктивных изменений, аналогично задаче Ant выше.
Бамбук позволяет клонировать среды. Хорошее практическое правило — работать в одной среде (например, Dev01), пока все не будет функционировать, а затем просто клонировать задачи для других сред, таких как Dev02, Dev03 и т. Д.
Слияние с Мастером
Со всем на месте Менеджер сборки просто должен использовать … | Функция « Создать релиз» в Bamboo после завершения этапа «Создать релиз». Релиз появится с именем, указанным менеджером сборки.
На этом этапе щелчок облачного значка развертывания рядом с каждой средой развернет код в соответствующей организации Salesforce. Bamboo позволяет отправлять уведомления по электронной почте и даже через Atlassian HipChat , чтобы ваша команда могла видеть ваш статус сборки.
Производственное развертывание должно быть настроено на выполнение последней серии git-команд:
git remote set-url origin ssh://[email protected]/crm/sfdc.git
git pull origin
git checkout -b release/${bamboo.release.name}
git config --local user.name "bamboo"
git config --local user.email "[email protected]"
git config --list --local
git checkout -f master
git merge --no-ff release/${bamboo.release.name}
git push origin master
Эти команды объединят код кандидата на выпуск в основную ветку. Как правило, после обновления Production я обычно обновляю все свои песочницы, чтобы все были на одном уровне кода, прежде чем мы начнем следующий спринт.
Вывод
Хотя Salesforce может быть лидером рынка в области CRM , он далеко от лидера рынка с точки зрения непрерывной интеграции. В этих статьях предпринята попытка обеспечить отправную точку для групп разработчиков DevOps, чтобы они могли организовать организацию Salesforce. Они далеки от завершения, потому что у каждой организации разные цели и потребности в процессе непрерывной интеграции.
Как я уже отмечал, для того, чтобы наша среда работала, потребовалось некоторое время, и я, конечно, понимаю, что она будет работать только до тех пор, пока она снова не сломается. В большинстве случаев проблемы связаны с неожиданными изменениями в Salesforce, а не с нашим дизайном и реализацией.
Хорошего дня!