Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Контроль змін та їх централізоване розгортання для Salesforce-проектів, використовуючи можливості СКВ

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Я — Роман Слободян, Software Engineer практики Salesforce у SoftServe.

Рік тому до нас зайшов великий ентерпрайс-проект з Healthcare домену. Перед цим на ньому працювало три розробницькі команди різних вендорів з різних часових зон. Усі вони використовували один адміністраторський акаунт та не мали розшареної між усіма історії змін. Відповідно, тут була низка проблем, які нам потрібно було вирішити перед тим, як приступати до основної роботи:

  • розсинхронізація середовищ;
  • непевність щодо джерела правди (source of truth);
  • частий перезапис змін одне одного.

Жодних інструментів для контролю версій чи централізованого розгортання релізів раніше на цьому проекті не використовували, міграція змін відбувалась вручну.

Ми пропонували цьому клієнту різні способи вирішення описаних вище проблем (SFDX, автоматизоване розгортання проекту з використанням Jenkins), але отримували однозначне «Ні» у відповідь. Тому всередині команди проводили брейнштормінг-сесії, щоб знайти інші варіанти.

Які інструменти обрали?

Одним із запропонованих варіантів було використання СКВ Bitbucket та вбудованого в неї функціоналу Pipeline’ів. Це рішення було компромісом між розумінням процесу кінцевим клієнтом та зусиллями і часом, що були необхідні для його впровадження та подальшої підтримки командою розробки.

Для реалізації цього рішення також необхідно бути знайомим з:

  • Bash — мовою для написання Shell-скриптів для *nix систем;
  • Ant Migration Tool — популярним інструментом для перенесення змін, який потребує мінімальних конфігурацій та може бути запущений використовуючи консоль.

Покрокове вирішення проблеми

1 — Обрати СКВ. У нашому випадку це Bitbucket, оскільки у клієнта вже був створений репозиторій під поточний проект, але його не використовували для контролю версій чи перенесення змін.

2 — Написати Shell-скрипт для розгортання метаданих безпосередньо з СКВ за допомогою Bitbucket Pipeline.

3 — Запустити скрипт прямо з СКВ через Web UI

4 — Перевірити результат у Salesforce

Технічні деталі

Для розгортання метаданих з СКВ потрібно конфігурувати саму систему.

Як це зробити в Bitbucket?

Крок 1 — Enable pipelines в Налаштуваннях та налаштувати їх для Java:

Враховуйте, що це можуть зробити лише ті, в кого є права адміністратора проекту.

Крок 2 — Configure repository variables (щоб не вводити їх щоразу в ручну)

Далі — Конфігурація Ant для виклику через Shell-скрипт написаний на Bash

Для початку ми додали файл з невеликою кількістю властивостей

Конкретно в цьому проекті ми маємо лише 1 скрипт в build.xml, який приймає arguments з Shell-скрипта і виконує розгортання.

В цій імплементації ми використовуємо bitbucket лише для недеструктивних змін, оскільки деструктивні тут трапляються дуже рідко. Це особливості імплементації конкретно цього проекту. Але, в разі необхідності, ви можете швидко підправити описаний підхід і для деструктивних змін також.

І package.xml

Як ви можете знати, не всі метадані, які отримуються з одного середовища, легко можна розгорнути в іншому. Може виникнути низка проблем з перенесенням деяких частин метаданих. Наприклад при перенесенні Permission Set’ів та Profile’ів необхідно звертати увагу на ліцензії середовищ; а при перенесенні конфігурацій табів не вийде просто розгорнути зміни через специфіку роботи Salesforce, і простіше перенести зміни або чейнджсетом, або взагалі вручну.

І сам Shell-скрипт

Тут скрипти досить прості. Вони визначають середовище і операцію, яку потрібно виконати (валідацію чи розгортання).

Розберемо детальніше. Середовище валідації:

Змінна:

Далі за допомогою Bash ми викликаємо Ant, передаємо деякі параметри для цього розгортання, як от логін і пароль користувача, від імені якого воно буде виконуватись:

Як тільки Ant виконує свою частину роботи, то починається розгортання на стороні Salesforce.

На цьому етапі нам було достатньо перевірити, чи успішно пройшло саме виконання (результатів у пайплайні ми не чекали, нижче поясню, чому). Залежно від цього, ми показуємо фінальний результат і закінчуємо виконання пайплайну з відповідним exitcode’ом.

А, наприклад, для продакшину ми вказуємо додаткову URL сервера:

На практиці це виглядає так:

Переваги цього методу:

  • Можливість застосовувати функціонал СКВ і Continuous deployment для старих проектів, на яких використовувались лише Change Set’и чи зміни взагалі переносились повністю вручну;
  • Легкість використання і підтримки;
  • Гнучкість і можливість планувати заздалегідь (деплоймент чи валідацію можна запланувати на конкретний час, наприклад на ніч);
  • Мінімізація вірогідності помилки під час деплойменту через людський фактор.

Недоліки:

  • Вірогідність труднощів з початковою конфігурацією. Складність впровадження напряму залежить від типів метаданих, які ви хочете зберігати в Bitbucket;
  • Необхідність хоча б базових знань з Bash, Ant Migration Tool, і Metadata API;
  • Бюджет (Усі операції, які виконуються в Bitbucket, займають час за який потрібно платити в разі перевищення лімітів (50 хв/місяць). Конкретно на цьому проекті ми ще ні разу не платили, оскільки написали Shell-скрипт таким чином, що він не очікує повного завершення розгортання на стороні Salesforce, а лише перевіряє результат виклику відповідної операції Ant`ом (деталі операції доступні на Deployment Status сторінці в Setup відповідного середовища). Але якщо у вас будуть занадто великі shell-скрипти, то це може коштувати досить дорого).
👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі