Лучшая практика развертывания Salesforce?

Question

В настоящее время мы экспериментируем с платформой Salesforce, чтобы заменить несколько собственных инструментов CRM, и уже развернут некоторый код.По мере роста нашей кодовой базы мы начинаем ощущать некоторые трудности, описанные другими, когда речь заходит об организации кода (нет хорошего пространства имен / упаковки и т. Д.).Мы являемся клиентами корпоративного уровня, и хотя в нашем текущем эксперименте в настоящее время задействован только один отдел, мы надеемся, что в конечном итоге он охватит всю компанию.

В организации, в которой имеется 3-4 совершенно разных группы продажКаждый из которых имеет разные бизнес-процессы и, следовательно, различное кодирование (в терминах SF: типы записей, макеты, триггеры и т. д.), каков хороший способ управления развертыванием?Являются ли «пакеты» подходящими для этого, или вся компания должна хорошо играть в одной и той же SF Org / пространстве имен?

Answer 1

Как правило, вам не понравится опыт разработки, потому что у вас есть три команды, каждая из которых будет пытаться установить свои системы. Каждый будет развиваться немного по-разному, потому что они найдут различные обходные пути для множества возникающих проблем.

Вы должны найти способ для пространства имен своих триггеров и классов: выберите префикс для каждой команды, чтобы отделить их код.

Используйте меньше больших классов: при программировании на традиционных ООП (например, Java) мне нравятся маленькие значимые классы. Но в Salesforce есть большие накладные расходы на управление классом. Плюс есть только одна большая папка для всех классов (гадость). Итак, теперь я создаю файлы большего размера. В каждый файл я включаю тестовый код. Я поместил тестовый код триггера в класс (например, контроллер), который работает с тем же объектом.

Чтобы отслеживать изменения и выполнять проверки кода, вы можете использовать эту технику: Используйте Force IDE в сочетании с системой контроля версий, такой как CVS, SVN, Mercurial или Git.
Настройте основной рабочий проект на включение всего (щелкните правой кнопкой мыши на проекте ... Force.com ... свойства проекта. В диалоговом окне настроек разверните Force.com и выберите «Содержание проекта». Нажмите «Добавить / удалить и добавить все»). Я не развернул изменения профиля из IDE обратно в производство таким способом. Делать это не может быть хорошей идеей. Но я отодвигаю апекс-классы, триггеры и страницы. Обратный путь при каждом сохранении медленный! Теперь используйте систему контроля версий для документирования изменений, а также для сравнения версий.

Развертывание из песочницы в производство: я отказался от использования инструментов развертывания пользовательского интерфейса. Они работают для простых вещей, но я обнаружил, что они не могут обрабатывать более сложные изменения (новые объекты, вкладки, приложения, триггеры, классы, страницы, макеты). Я перемещаю изменения по частям из песочницы в производство. С тремя командами это означает, что вам может понадобиться центральная команда, которая развертывает окончательные изменения?

Есть много способов разделения ваших систем, включая типы записей. Для этого требуется код, который либо содержит жестко закодированный SF Id, либо использует строку для выполнения поиска. В обоих случаях вы не хотите распространять эти строки или идентификаторы по всему коду. Подумайте о кошмаре, когда вам нужно провести рефакторинг. Вместо этого создайте класс Globals и поместите здесь все свои жестко закодированные имена и идентификаторы. По крайней мере, вы можете выполнить более разумный поиск и заменить.

Я люблю SF. Некоторые вещи очень легко сделать. Но некоторые задачи разработки, похоже, занимают очень много времени. Удачи

Answer 2

Как правило, вы хотите убедиться, что у каждого есть свой код и конфигурация, работающие в одной конкретной песочнице, чтобы вы могли быть уверены, что все различные части работают правильно вместе и не вызывают нежелательных эффектов.Типы записей являются особенно удобным механизмом, поскольку вы можете использовать их, чтобы определить, какую логику следует запускать внутри триггеров и т. Д. Для конкретной записи, в сочетании с хорошей схемой именования люди будут знать, куда помещать код, если что-то уже существует, например, имея такойТриггер на аккаунте до обновления проще поддерживать, чем два.Вызов триггера «Account_BeforeUpdate» позволит всем знать, что это такое, поэтому, если им нужно использовать один, они могут затем поместить свой код в существующий триггер, работая только с определенными типами записей, только если это необходимо.

Одна вещьЯ всегда делаю перед развертыванием настройку производственного проекта внутри Eclipse вдоль песочницы, чтобы убедиться, что в нем есть все, что мне нужно (макеты и т. Д.).Затем вы можете использовать инструмент сравнения, чтобы точно выяснить, какие изменения существуют между песочницей и производством, что является чрезвычайно ценным знанием.Однако здесь следует с осторожностью относиться к тому, что макеты и т. Д. Будут часто обновляться в рабочей среде после того, как песочница будет разрезана, что означает, что вам, возможно, придется быть осторожным в отношении их развертывания.

Обычно объекты являются первымиЯ двигаюсь, и поскольку API не разрушителен, вы можете быть уверены, что не удалите какие-либо важные поля из производства!

Лично я действительно с нетерпением жду какого-то достойного контроля версий в Salesforce, вы всегданужно проявлять осторожность, если у вас есть несколько разработчиков, работающих в одной и той же области, даже если она пытается защитить вас от перезаписи изменений других, это случалось с нами несколько раз.Надеюсь, что это пригодится!