Огляд Salesforce CRM. Фронтенд, середовища розробки і корисна література. Частина 2

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

Привіт! Нагадаю, що звуть мене Іван Левицький, і вже чотири роки я займаюся Salesforce-розробкою. У першій частині статті я розповів про базу даних в Salesforce і мову Apex, готові рішення і функціональні можливості Salesforce. У другій — йтиметься про фронтенд, процес, засоби, середовища розробки і те, кому, на мою думку, варто уважніше придивитися до Salesforce з кар’єрного погляду. Зазначу, що я не впевнений, що він підійде всім.

Гадаю, продовження статті буде корисно прочитати і тим, хто вже працює з Salesforce. Наприкінці я розмістив добірки корисних посилань, розширень, онлайн-сервісів і літератури. Їх я склав особисто та перевірив на власному досвіді.

Ілюстрація Марії Рибак

Фронтенд

Дуже багато запитів від клієнтів стосуються створення, переміщення та перейменування полів. У Salesforce все це можна зробити без програмування.

Як згадувалося раніше, Salesforce має дві версії користувацького інтерфейсу: стара Classic і нова Lightning, на яку вже перейшла більшість клієнтів.

Lightning

Classic версія UI

Одним із перших інструментів для створення власного UI був SControl — здебільшого це були HTML Web Forms. Зараз можливості використовувати SControl немає, але Salesforce продовжує підтримувати інтерфейси, створені за його допомогою раніше. Їх часто можна побачити у сторонніх пакетах, розробка яких почалася багато років тому.

Особливістю Classic-версії були JavaScript Buttons, що за допомогою JavaScript API могли виконувати найпростіші маніпуляції або викликати Apex-код. Аналогом JavaScript кнопок у Lightning-версії стали Lightning Quick Actions.

В обох версіях UI всі елементи групуються у вкладки (tabs), які групуються в App. У Lightning-версії всі Apps групуються в App Launcher. Зазвичай для одного об’єкта є одна вкладка. Вкладкою може бути окрема компонента, App-сторінка, Record-сторінка або вбудований через iFrame сторонній вебресурс.

Наразі власний UI можна створити за допомогою таких технологій:

1. VisualForce (VF) — найстаріша з доступних технологій. Сторінка або компонента генерується на стороні сервера, проте Apex-код і розмітка сторінки пишуться окремо. Передбачено функціонал для оптимізації роботи сторінки. Деякі елементи VisualForce досі важко замінити: наприклад, просунутий email template, генерацію PDF-файлів, розробку власної сторінки SObject List.

2. Aura Framework (або просто Aura), що виникла водночас із новим графічним інтерфейсом Lightning. На відміну від VisualForce, сторінка тут генерується на боці клієнта, тобто в браузері користувача. Дає змогу передавати змінну між батьківськими та вбудованими компонентами за значенням і за посиланням. Зв’язок у цьому випадку двосторонній. Для більш складних випадків використовують component і application events. Останній, по суті, є реалізацією publish-subscribe механізму.

Є можливість викликати та підписуватись на деякі системні події. Також можна через EMP API підписатися на Platform Events. Є безліч обробників для ініціалізації та різних етапів рендерингу компоненти.

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

Кожна Aura-компонента (Aura bundle) може складатися з таких частин: component (HTML-розмітка сторінки), controller (JS-контролер, звідки функції можна прив’язати до подій на боці розмітки), helper (тут міститься основна частина JS-коду), style (CSS), documentation (документація до компоненти), renderer (для перевизначення процесу рендерингу), design (тут можна задавати атрибути з графічного конструктора) та svg (svg-іконка компоненти). Проте для її створення обов’язковим є тільки component.

Якщо треба сформувати бібліотеку JavaScript-функцій, можна створити component із порожнім тегом <aura: component> або окремий JS-файл. Останній завантажується у Static Resources, після чого ви зможете підключати його до своєї компоненти.

3. LWC (Lightning Web Components) — найновіша з доступних технологій, у деяких аспектах не така гнучка, як Aura Framework (binding, динамічне створення компонент тощо). Проте ці недоліки компенсуються стандартами та можливостями Web Components: після їхньої стандартизації Salesforce і запустив LWC. Тут для однієї компоненти може взагалі не існувати HTML-розмітки або ж їх, навпаки, може бути відразу декілька. Серед усіх перерахованих технологій LWC є найбільш спритною.

Для створення швидкого та стандартизованого з LEX (Lightning EXperience, Lightning UI-версія) інтерфейсу існує бібліотека стилів, схожа на Bootstrap, — SLDS (Salesforce Lightning Design System). Для Aura-компонент чи LWC вона під’єднується автоматично. Для Aura Apps і VisualForce SLDS треба підключити самостійно. Докладніше про SLDS можна прочитати тут.

Увесь JavaScript-код, написаний для Aura і LWC, автоматично виконується в режимі use strict, до того ж Salesforce ввів ще й Locker Service. Це рішення безпеки для фронтенду: наприклад, дані з сервера передаються у вигляді Proxy-об’єктів, а частина JavaScript-функцій та HTML-розмітки залишаються недоступними. Це підвищує рівень безпеки, але дуже ускладнює розробку кастомного користувацького інтерфейсу. Докладніше про Locker Service — тут.

Інші технології, гідні згадки: Lightning Out, яка, наприклад, дозволяє вбудовувати Aura-компоненти у VisualForce чи на сторонні сайти, та Lightning Message Service, що надає можливість обміну даними між Aura, LWC та VF-компонентами. Також є вбудований функціонал для забезпечення безпеки: CSP (Content Security Policy) та CORS (Cross-Origin Resource Sharing).

До того ж для Aura та LWC можна писати юніт-тести.

Кожна технологія має низку стандартних компонент, деякі з них можна розширювати. Для Aura та LWC є бібліотека Lightning Component Library, для VisualForce — VisualForce Component Library.

Вбудовані засоби декларативного програмування

Багато чого у Salesforce можна зробити вручну за допомогою графічного інтерфейсу. Наприклад, створити об’єкт, поля та валідації на об’єкті або налаштувати розташування елементів на сторінці. До того ж Salesforce містить низку вбудованих інструментів декларативного програмування.

На деяких проєктах (переважно невеликих і таких, де клієнт має свого адміністратора) використовувати декларативні засоби програмування просять надзвичайно наполегливо — практично вимагають. Клієнтів зрозуміти можна: підключати фахівця з боку — задоволення для малого бізнесу недешеве. Тому вони хочуть мати рішення, які можна легко змінити без допомоги розробника. Звичайно, коли пишеш код, можна винести деякі змінні назовні та детально задокументувати процес. Але багато замовників все одно цінують саме декларативні рішення. Чому? По-перше, на ринку порівняно легко знайти сертифікованого адміністратора, який за дуже короткий час внесе необхідні зміни, не розбираючись у кастомних налаштуваннях. По-друге, декларативне програмування прискорює розробку, зокрема, відпадає необхідність писати юніт-тести.

Проте у великих проєктах від декларативних інструментів найчастіше відмовляються через Order of Execution, можливу ​​рекурсію та небезпеку виходу за Governor Limits.

Хоча у Salesforce багато інструментів можна віднести до декларативних, зазвичай під цим терміном розуміють один з таких: Workflow Rules, Process Builder, Flows (Visual Flow) і Approvals.

1. Workflow Rules — найстаріший з цього списку. Прив’язується до певного об’єкта. Може виконувати такі дії: створювати завдання (Task), надсилати Email Alert, надсилати Outbound Message для зовнішнього вебресурсу, оновлювати запис, на якому спрацював тригер, та деякі поля master запису за наявності зв’язку master-detail. Workflow може бути запущено при створенні запису прив’язаного об’єкта вперше або щоразу, коли виконується певна умова. Дозволяє створити time-based Workflow.
2. Process Builder надає підтримку різних версій одного процесу та можливість активувати, деактивувати чи видалити його. Дозволяє вибудовувати логіку, що містить багато конструкцій виду if-else. Може редагувати не лише запис, який ініціював процес, а й усі пов’язані записи. Забезпечує можливість створювати записи у системі (не лише Task), оновлювати пов’язані записи, публікувати повідомлення у Chatter, запускати Flow, викликати Invocable Apex-код, подавати запис на Approval, викликати інший процес.
3. Flows (Visual Flow) зазвичай не прив’язуються до об’єктів. Здатні замінити собою написання коду для простих задач і деяких задач середньої складності. Тут кожен Flow можна використовувати як subFlow в іншому Flow. Є декілька видів:
   
   • Screen Flows — для створення користувацького інтерфейсу;
   • Schedule-Triggered Flows — Flows, заплановані на певний час;
   • Autolaunched Flows — потоки, що можуть бути викликані з Process Builder чи Apex, при зміні записів або бути підписаними на Platform Events;
   • Record-Triggered Flows — цей тип Flows запускається у фоновому режимі, коли запис певного об’єкта створюється, редагується чи видаляється;
   • Platform Event-Triggered Flows — підписані на Platform Events і запускаються щоразу, отримавши Platform Event-повідомлення.
4. Approval дозволяє автоматизувати процес ухвалення рішень.

Розгортання, CI/CD та DevOps

У жовтні 2017 року для загального доступу було відкрито CLI від Salesforce — SFDX CLI (SalesForce Developer Experience Command Line). Сам CLI написаний на Node.js, тому легко може бути інтегрований у CI/CD-процес навіть на боці VCS (Version Control System), чи то GitHub, чи то GitLab. Ще одна важлива особливість SFDX — можливість дуже швидко створювати Scratch Orgs, видаляти їх та деплоїти на них метадані. Це не лише прискорює процес розробки, а й знаходить широке застосування при CI/CD.

Деплоймент у Salesforce можна проводити декількома способами:

• Change Sets — набори змін можна легко переносити між пов’язаними «пісочницями» та Production-оргою.
• Ant — можна деплоїти зміни і destructive changes через Ant.
• IDE — метадані деплояться через Metadata API.
• SFDX CLI — є можливість деплоїти метадані, перераховані у package.xml.
• Workbench — є можливість деплоїти метадані через архів, що містить змінені метадані та їхній список у package.xml.
• Сторонні сервіси, як-от GearSet, Flosum і багато інших.

Назабаром загальнодоступним стане Salesforce DevOps Center, який стане ще одним з можливих шляхів розгортання змін.

Розробка власних пакетів

Я вже згадував, що Salesforce надає можливість розробки власних пакетів, здатних розширити наявний функціонал. Розповсюджувати їх можна безкоштовно або за підпискою, за посиланням або через офіційний магазин застосунків AppExchange. Щоб випустити свій пакет на AppExchange, необхідно бути Salesforce-партнером та пройти Security Review. Розповсюджувати компоненти можна з відкритим (unmanaged package) або прихованим (managed package) кодом.

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

За допомогою пакетів можна розширити стандартний функціонал, створити новий, зробити інтеграцію зі стороннім ресурсом. Можливості тут широкі: підтримка версій, post install скрипти, setup-сторінки, створення бета-версій пакетів, зберігання налаштувань у custom settings чи custom metadata type. Якщо клієнт надасть доступ, можна протестувати пакет на Salesforce org того, хто його встановив. І це далеко не повний перелік.

Процес розробки на Salesforce

Для розробки на платформі Salesforce найчастіше застосовується методологія Agile (двотижневий спринт), рідше Kanban. Трапляється, але значно рідше, і Scrum.

Типовий процес розробки

• Development — розробник працює над функціоналом у своїй «пісочниці» (sandbox) чи Scratch-орзі. Дуже рідко для цього етапу використовують окрему Developer-оргу.
• Staging (QA Testing) — зміни, внесені розробником, переносяться в інший sandbox: найчастіше таку «пісочницю» так і називають: QA або Staging. Тут QA-інженер тестує та верифікує зроблені зміни.
• UAT — етап, коли один зі стейкхолдерів проєкту перевіряє зміни. Зазвичай для цього використовується окрема «пісочниця», куди частково чи цілком копіюють дані з Production (так звані Full aбо Partial Copy Sandbox).
• Deployment on Production — після перевірки тестувальником і клієнтом зміни потрапляють у Production. Безпосередньо код чи розмітку якоїсь компоненти змінювати у Production не можна: пам’ятайте, що принцип «раз-раз — і в продакшен» у Salesforce не спрацює. Виняток становлять декларативні зміни.

Salesforce APIs

Salesforce позиціонує себе як API-first, але так було не завжди, тому частина старого функціоналу може не бути доступною через API.

Нижче представлений список найпопулярніших Salesforce API:

• REST API забезпечує потужний, зручний і простий інтерфейс вебслужб на основі REST для взаємодії з Salesforce. Його використовують для інтеграції з мобільними застосунками і вебпроєктами.
• SOAP API — SOAP-версія API для взаємодії з Salesforce. Аналогічна за функціоналом з REST API, вона заточена на роботу з real time запитами.
• Bulk API — заснований на REST-принципах інтерфейс для роботи з великим набором даних.
• Metadata API — API, що використовується для отримання, розгортання, створення, оновлення та видалення налаштувань для конкретної організації. Найчастіше — для перенесення змін з «пісочниці» чи тестової орги на Production.
• Tooling API — своєрідний мікс REST і Metadata API, що дозволяє робити SOQL-запити для метаданих, недоступних для звичайного SOQL. Здебільшого використовується розробниками IDE.

До того ж деякі Salesforce Clouds, особливо ті, які спочатку були незалежними компаніями, мають власний REST-based API. Наприклад, Connect REST API (Chatter, CMS, Experience Cloud), Marketing Cloud API, Pardot API тощо.

Для своїх API Salesforce використовує версіонування. З кожним новим релізом порядковий номер версії збільшується на одиницю. Salesforce завжди стабільно випускає три релізи протягом календарного року: Spring, Summer, Winter.

Компанія гарантує щонайменше три роки підтримки кожної API-версії.

Середовища розробки (IDE)

• VS Code + набір різних плагінів для роботи з Salesforce, зокрема офіційних. Особисто я ними не користуюся, тому можу порекомендувати почитати цю статтю. Але переваги тут цілком очевидні: офіційні плагіни, до того ж усе безкоштовно.
• IntelliJ чи WebStorm + Illuminated Cloud 2 — особисто користуюся цим набором вже кілька років і не планую нічого змінювати. Переваги: значно функціональніший, ніж офіційні та сторонні плагіни для VS Code. Недоліки теж є: і сама IDE, і плагін є платними.
• Welkin Suite — популярна IDE, розробка української компанії. Основою для середовища стала застаріла Visual Studio 2013 від Microsoft. Welkin Suite має низку можливостей, аналогів яким немає в інших IDE. Здебільшого вони пов’язані з автоматизацією адміністрування. Недоліки: платна, рідко оновлюється, не підтримує LWC, до того ж інтерфейс перевантажений великою кількістю кнопок.
• Developer Console — офіційний web-based інструмент від Salesforce. Доступний на всіх Developer-оргах та на тих Production і Sandboxes, де це передбачено придбаною ліцензією. Консоль доступна за адресою https://SF_INSTANCE_URL/_ui/common/apex/debug/ApexCSIPage, де SF_INSTANCE_URL — це адреса вашої Salesforce org. Переваги: ​​підходить для незначних змін, створення VF та Aura-компонент і аплікацій, статичних ресурсів; є SOQL-запити з підтримкою Tooling API; дозволяє запускати Anonymous Apex і юніт-тести, причому демонструє покриття коду; допомагає налагодженню коду, декларативного функціоналу та взагалі майже всього, що відбувається на боці сервера; дозволяє налагоджувати й оптимізувати VF-сторінки; надає можливості моніторингу розгортань. Недоліки: не підходить для комплексних задач, підвисає при великій кількості відкритих вкладок, не підтримує роботу з LWC.
• Salesforce Code Builder покликаний замінити Developer Console та бути повноцінною web based IDE. Уже майже рік доступний у пілотній версії. До неї можна отримати доступ, але для цього треба зв’язатися з представником Salesforce, прикріпленим до вашого Salesforce-інстансу. Докладніше можна прочитати тут.

Корисні розширення для Chrome, програми та онлайн-сервіси

Корисні розширення

Серед розширень для Chrome я рекомендую такі:

1. Salesforce Inspector (100 000+ користувачів) — дає змогу переглядати всі поля та зв’язки на запису, навіть якщо вони не виводяться на екран для кінцевого користувача, імпортувати/експортувати дані, перевіряти Org Limits та входити під акаунтами інших користувачів (Login As). Великий плюс — можливість робити SOQL-запити, зокрема Tooling API.
2. Salesforce Colored Favicons (20 000+ користувачів) — маленьке, але теж дуже корисне розширення. Оскільки всі Salesforce-орги мають однакові favicon, це розширення дозволяє автоматично змінювати кольори цих favicon для різних Salesforce Instances.
3. Salesforce Lightning Inspector (50 000+ користувачів) — офіційне розширення від Salesforce, що дає змогу налагоджувати Aura-компоненти. Воно отримало невисокі оцінки користувачів, здебільшого через проблеми з продуктивністю. Але якщо ви досі працюєте з Aura-компонентами, це розширення буде для вас корисним: за його допомогою можна зрозуміти, як влаштовані та функціонують Aura Framework і LEX (Lightning Experience).
4. Salesforce.com Enhanced Formula Editor (5000+ користувачів) — незамінний інструмент для Salesforce-адміністраторів, меншою мірою для розробників. Підсвічує синтаксис при написанні формул та взагалі спрощує роботу з ними, чи то Formula-поле, чи то формули у Validation Rules, Flows, Process Builders, Workflow Rules і field update formulas. Розширення платне, але є пробна версія на чотирнадцять днів.
5. Salesforce Community Page Optimizer (5000+ користувачів) — ще одне офіційне розширення від Salesforce. Дозволяє оптимізувати сторінки в Experience Cloud (раніше Community Cloud).

Часто натрапляв на використання розширення Salesforce Logins by Synebo (20 000+ користувачів), розробленого українською компанією.

У щось корисне обіцяє розвинутись Advanced Salesforce inspector, натхнене, як неважко здогадатися, Salesforce Inspector. Розширення — на ранній стадії розробки, але хтозна, можливо, за рік-півтора про нього почнуть писати всі.

Корисні програми для роботи з Salesforce

Крім середовищ для розробки та SFDX CLI, є програми, без яких важко уявити роботу з Salesforce:

1. Data Loader — його можна завантажити з Setup Salesforce-інстансу. Це, зокрема, гарантує, що версія вашого Data Loader буде збігатися з API version вашої Salesforce-орги. Дає змогу імпортувати, експортувати, оновлювати та видаляти дані з Salesforce-орги, проводити заливку даних через Bulk API (завдяки чому в одному пакеті можна мати до 10 000 записів). Версія для Windows має CLI, тож її теоретично можна використовувати на Windows-серверах; існує версія і для macOS. Підтримуються майже всі об’єкти у Salesforce, зокрема кастомні.
2. Postman — програма для роботи з API. Не потребує додаткового представлення.
3. Advanced Rest Client (ARC) — майже те саме, що й Postman, але з меншим об’ємом функціоналу. Проте з простими задачами впорається на ура.
4. SoapUI — корисна для роботи з SOAP API.

Корисні посилання для роботи з Salesforce

1. Dataloader.io — сайт для міграції, імпорту, експорту даних у/з Salesforce. Компанія була викуплена Salesforce, тому можна не перейматися щодо безпеки даних. Серед можливостей: розумний mapping даних; конектори для Box, Dropbox, FTP і SFTP-репозиторіїв; можливість запланувати роботу з даними. Доступна безкоштовна версія з обмеженнями, Professional та Enterprise-версії (для останньої передбачений 30-денний trial).
2. Workbench — офіційний багатофункціональний web-based інструмент із Salesforce. Підтримує CRUD, Undelete і Purge (повне видалення) операції, перегляд, retrieve і deploy метаданих; дозволяє виконувати SOSL, звичайні й асинхронні SOQL-запити, запускати Apex і REST Explorer, задавати та скидати паролі для користувачів тощо.
3. JSON2apex і Adminbooster — сайти для генерації Apex-класів на основі JSON. Для XML у Salesforce є вбудований функціонал.
4. Flosum — DevOps-сервіс, розроблений колишнім співробітником Salesforce.
5. Gearset — ще один функціональний DevOps-сервіс для роботи з Salesforce.
6. Infostretch — розумний Continuous Testing & Automation-інструмент для Salesforce.
7. JSON Viewer — інструмент для візуального представлення JSON, не унікальний, зате простий у використанні.
8. MuleSoft — платформа, яку часто використовують для розробки інтеграції з Salesforce. Раніше це був продукт компанії, яку поглинув Salesforce.
9. Boomi — ще одна платформа для інтеграції, але застаріла і менш популярна.

Корисна література

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

Trailhead містить уроки (так звані trails, що об’єднуються у Trail Mix) для фахівців різних рівнів підготовки. Для отримання деяких Salesforce-сертифікатів потрібно пройти розв’язання комплексних задач, так званих Super Badge. Особливість цих задач у тому, що, на відміну від інших типів, тут немає чітко сформульованої умови (майже як у реальному проєкті) та готових прикладів розв’язання.

Проте, попри всі переваги Trailhead, для повноцінного розвитку його все ж недостатньо. Тому серед безлічі книг про Salesforce я вибрав декілька, на мій погляд, найбільш важливих і корисних. Насамперед вони орієнтовані на розробників.

Книги для розробників

1. Magulan D «Getting Started with SOQL» — хороша книга для ознайомлення з SOQL, особливо для тих, хто раніше працював лише з SQL.
2. Keir Bowden «VisualForce Development Cookbook». Хоча VisualForce вже застаріла, розробникам досі доводиться з нею стикатися. Зокрема, для генерації PDF-файлів і перевизначення List View сторінок або на старих проєктах. Книга містить 75 готових VisualForce-рішень.
3. Jitendra Zaa «Apex Design Patterns» буде цікавою для тих, хто хоче освіжити знання про шаблони програмування чи просто подивитися на їхню Apex-реалізацію.
4. Andrew Fawcett «Salesforce Lightning Platform Enterprise Architecture, Third Edition» — книга Ендрю Фосетта, який свого часу був визнаний Salesforce MVP. Буде корисною для Salesforce Team Lead та Salesforce Architect.
5. Mohith Shrivastava «Learning Salesforce Lightning Application Development» — трохи застаріла, але відмінно підійде, якщо вам досі доводиться працювати з Aura.
6. David Masri «Developing Data Migrations and Integrations with Salesforce» — книга, яка мене приємно вразила: фундаментальний огляд Salesforce, огляд і приклади міграцій та інтеграцій.
7. Andrew Davis «Mastering Salesforce DevOps» — назва говорить сама за себе.

Книги для адміністраторів

1. Paul Goodey «Salesforce CRM — The Definitive Admin Handbook, Fifth Edition».
2. Philip Weinmester «Practical Salesforce Development Without Code, Building Declarative Solutions on the Salesforce Platform, Second Edition».
3. Rakesh Gupta «Mastering Salesforce CRM Administration».

Тим, хто цікавиться історією становлення компанії, рекомендую почитати спогади її засновника: Marc Benioff and Carlye Adler «Behind the Cloud, the untold story of how Salesforce.com went from idea to billion-dollar company and revolutionized an industry».

Висновок

Протягом кількох останніх років для Salesforce-розробників багато що змінилось. Компанія випустила власний SFDX CLI, написаний на Node.js, який легко можна додати в докер та використовувати для CI/CD або чогось менш глобального. Salesforce переписав плагін для IDE, та й саму IDE змінили з Eclipse на VS Code. Хоча найбільш функціональним набором для розробки залишається зв’язка IntelliJ IDE (або Webstorm) і плагіну під назвою Illuminated Cloud 2. Також знаковою подією для розробників стала підтримка Web Components, LWC (Lightning Web Components).

Кому з розробників може бути цікавим Salesforce?

• Фронтенд-фахівцям, які хочуть розвиватись у бік бекенду, але не впевнені, чи зможуть потягнути високорівневу мову програмування.
• Salesforce може стати рятувальним колом для фахівців з мов програмування, які різко втратили у популярності.
• Може слугувати хорошим стартом кар’єри розробника, хоча я особисто не рекомендував би надовго тут затримуватися.
• Підійде тим, хто просто не встигає за розвитком різних фреймворків і хоче спокійнішого життя. Або тим, кому набридло паралельно з посадою розробника виконувати у проєкті ще й обов’язки DevOps-інженера.

Тим, хто у програмуванні зовсім не сильний, Salesforce теж може допомогти перезапустити кар’єру. Вони можуть стати адміністраторами чи консультантами. Платформа пристосована для конфігурацій з UI-інтерфейсом та має багато інструментів для декларативного програмування.

Увесь Salesforce добре документований, для розробників і адміністраторів існує Salesforce Developer Community та окремий Stack Exchange. До того ж працює служба підтримки, яка за день-два допомагає з простими проблемами. Найскладніший випадок спілкування з Salesforce Support тривав у мене два тижні.

Якщо вас цікавить рівень зарплат у Salesforce, з ним можна ознайомитися, завантаживши звіт від авторитетної компанії Mason Frank International.

Я не хочу прикрашати й рекламувати Salesforce. Так, для розробників тут багато такого, що пропонують і інші середовища програмування: пропріетарна Java-подібна мова програмування для бекенду, три різновиди компонент для фронтенду, свій CLI, підтримка VCS, безліч API тощо. Але Salesforce — це передусім CRM-система. Чи цікаво вам працювати з рішеннями, що будуються навколо неї — вирішувати тільки вам.