А как сделать хороший и чистый орг?

 - SFDX предполагает интегрирование и с VC и с CI/CD.
 - Docs - ApexDocs
 - Communication – встроенный Chatter, возможно не худший вариант, но ИМХО, лучше использовать решение из пакета 
 - GitHub/Atlassian etc
 - Trigger pattern - этот один из лучших: https://github.com/kevinohara80/sfdc-trigger-framework

 - Proper way to control code by custom metadata - не понял?

У меня это скорее обсуждение в вольной форме :)

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

По поводу metadata, это когда ты можешь задавать переменные коду из метадаты. Например детали интеграций, фильтры для батчей или контролировать какие экшены в тригеррах активны или нет. Позволяет удобно контролировать код без надобности деплоить его опять. В больших оргах очень удобно с этим работать.

[quote="AntonB"]переменные коду из метадаты[/quote] В зависимости от задачи, возможно Hierarchy Custom Setting, Custom Metadata

[quote="AntonB"]А как сделать хороший и чистый орг?[/quote]

со всеми пунктами,согласен. еще бы добавил использование custom labels для ошибок, нотификейшнов и прочего. Ну и тест классы не только для покрытия.

[quote="AntonB"]Всем привет!

Интересно услышать мнение опытных людей. 

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

По этому вопрос, как в вашем понимание выглядит идеальный сейлсфорс орг? Со стороны кода и с конфигураций.


В моем понимание это орг в котором буду преследоваться такие практики:

- Trigger pattern
- Clear naming conventions for fields, classes
- Clean correlation between declarative processes and code
- Version control
- Good documentation (Process and technical)
- Fast deployments, instead of the scheduled releases
- Continuous development and deployment
- Proper way to control code by custom metadata
- Clear communication between developers and admin people

Какие мысли? Что бы вы добавили?[/quote]

Eсли у вас будет один человек, Админ, а все остальные юзеры без доступа к Сетапу, тогда нечего беспокоиться, но если таких человеков будет больше, то стоит ожидать что в один прекрасный день появятся рандомные филды, не соответствующие паттернам :) Их могут создать прямо на проде, навешать кучу рулов, и тд и тп.
А могут создать на рандомном сандбоксе и залить в прод мимо гита и мимо админа

А девелоперы и админы должны общаться вне Салесфорса, это однозначно. Jira с тасками и комментами хорошее место. Документацию вести в Confluence или чем-то похожим, но только не в гуглодоках/квипах и тд(не надо изобретать велосипеды)

Самый стрем из всего списка как по мне - - Fast deployments, instead of the scheduled releases.

Это значит меньше внимания качеству кода, документации, тестированию. Вместо хорошего релиза в любой момент улетит кусок говна в прод(дай бог чтобы ничего не поломал) - и получится то что написано выше.

[quote="AntonB"]По поводу metadata, это когда ты можешь задавать переменные коду из метадаты.[/quote]
Главное не путать с лейблами, а то на просторах куча умельцев кто айдишки/апи ключи в лейблах хранит

[quote="AntonB"]что орг совсем маленький еще.[/quote]какое примерно кол-во пользователей? сегодня и в недалеком будущем? 
5, 10, 100, > 1000

всё что ты написал хорошо и правильно, но если орг действительно маленький, то немного перебор на мой взгляд

[quote="Maxim Elets"]Это значит меньше внимания качеству кода, документации, тестированию. Вместо хорошего релиза в любой момент улетит кусок говна в прод(дай бог чтобы ничего не поломал) - и получится то что написано выше.[/quote]

Под  "Fast deployments, instead of the scheduled releases" имел ввиду практики continuous development, например чтобы код из гита переодически ранил тесты к продакшену, чтобы все тесты работали постоянно и чтобы убедиться что никакие изменения их не ломают. 

Мне кажется в этом есть плюсы того что можно делать быстрые bug fixes. Плюс к этому при имлпементации проекта, не надо деплоить огромный функционал одним большим деплойментом, код может отправляться по частям более легкими и быстрыми деплойментами. Если нормально тестить функционал и иметь отдельный сандбокс для этого, то проблем с багами должно быть меньше, а гавно из кода можно убирать если использовать code reviews и покрывать это нормальными, работающими тестами.

[quote="Eric"][quote="AntonB"]что орг совсем маленький еще.[/quote]какое примерно кол-во пользователей? сегодня и в недалеком будущем? 
5, 10, 100, > 1000

всё что ты написал хорошо и правильно, но если орг действительно маленький, то немного перебор на мой взгляд[/quote]

Согласен, что возможно перебор, пытаюсь выбрать что то хорошее из практик больших оргов. Пока что юзеров около 500. Но надеюсь, что будет становиться больше.

Все это конечно красиво звучит пока не начнет пилиться. 
И на первых парах даже будет выглядеть красиво если на проекте будет <2 людей (проверено на практике не раз).
Самый важный момент - делать все как можно проще ([url=https://ru.wikipedia.org/wiki/KISS_(%D0%BF%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF)]KISS[/url]).

Но если придираться к самому вопросы - вы хотите сделать "хороший и чистый орг" или наладить красивый процесс разработки? Тут можно одно быть хреновым, а другое офуенным и наоборот.

[b]На счет чистого орга[/b] вот мои пять копеек:
- минимум (а лучше никаких) слоев абстракции типа fflib (как показывает практика ничего хорошего из этого не выходит) - это опять же из темы KISS. Надо какой-то слой абстракции написать - напишите сами, а не тяните тонны чужого говнокода, который будете использовать на 10%.
- используйте минимум SF фич! - Apex + VF/LWC. Нахер все process builders, validation rules, flows и прочей красивой админской херни. Как только начнете их использовать ждите беды с дебагом багов в скором времени. 

А в общем если вы за главного и в скором времени ожидаются коллеги по цеху в комманду, то начните с простого - с описания Code Styles Guide (вышеупомянутые Trigger pattern, Clear naming conventions) и введение обязательного code review на уровне Pull Requests. Причем Code Styles Guide должен быть предельно простым - на два листа A4 чтобы любой джун мог его осилить. 

[b]На счет процесса разработки[/b] - простейшие истины:
- каждый разраб работает на своем дев орге (отдельном сандбоксе если есть возможность)
- все взаимодействие через git
- деплой на прод только вручную самым отвественным человеком (то есть вами)

Делайте все проще и будет счастье. 

Не надо заниматься прокрастинацией, а надо просто брать и делать :). Все равно рано или поздно на проект придет другой разраб который считает что знает больше вас и все ваши выстроенные процессы пойдут лесом.

ЗЫ: Этот пункт "Clear communication between developers and admin people" тоже выпадает из первых двух. Это уже третье направление - управление компанией.  

Дмитрий, спасибо за развернутый ответ! Много полезного подчерпнул!

Хотел спросить по поводу этого пункта: 

[quote="Dmitry Shnyrev"] каждый разраб работает на своем дев орге (отдельном сандбоксе если есть возможность)[/quote]

Как именно будет выглядеть процесс вместе с гитом, с отдельными дев оргами? 

Мне представляется это так, что будет общий сандбокс для того чтобы мержить фичи. Из него будут делаться дев оргы для каждого программиста. Это ведь должно происходить достаточно часто, практически каждую новую фичу? Для того чтобы у нескольких программистов был up to date код. И по завершению каждой новой фичи должно все заливаться в этот сандбокс по середине? В гите это может выглядеть как новый дев бранч который будет отображать дев орг? 

Каково будет преимущество использовать такую модель, чем иметь один санбокс для разработки, где будут работать несколько девелоперов? Только в том, что они не будут переписывать код друг друга, если работают с одними классами?

Такое вот с отдельными оргами, наверное можно попробовать красиво сделать со scratch orgs, они вроде бы для этого как раз предназначены? Пока только игрался с ними в своем дев орге, в работе не пробовал. 

[quote="AntonB"]Как именно будет выглядеть процесс вместе с гитом, с отдельными дев оргами?[/quote]
Данный процесс будет выглядеть просто супер. Собственно так как работает весь остальной НЕ SF ИТ мир. 

Начну с того почему нельзя делать так как вы написали
Если все будут заливать код в один сандбокс и только из него будет делаться гит то 0 цена такому гит. Во первых это тоже самое что несколько разрабов работает на одном сандбоксе. Все друг друга будут перетирать. Простой пример - два дева сделали по оргу и начали пилить фичу. Через неделю оба закончили и пошли заливать свой код на этот мастер сандбокс (назовем его так). Кто будет папа? Правильно кто последний зальет. Я даже не представляю как можно разруливать конфликты в таком случае.

Если разрабы имеют свои орги и работают через гит - тут все создано для совместной работы - вот тебе и PRs и diffs и branches. Да это не стоит даже описывать если вы пользовались гид до этого. А выглядеть это будет так. Source of truth - это гит. Из него код берется чтобы заливать на любые орги. Дев создал орг, подключил гит репо к проекту, слил последнюю версию проекта и задеплоил себе на орг. После изменений закомитил все в гит. В тот же самый мастер сандбокс (как и любой другой UAT, pre-UAT, QA, ...) код тоже попадает исключительно из гит, а не откуда попало и от кого попало. Да, такая работа с гит немного сложнее чем просто сидеть куче разрабов на одном санбоксе и переписывать изменения друг друга. Но более менее опытный SF дев, который знает что такое ant и git вполне может настроить все правильно. 

На счет scratch/обычный орг. Я бы пока не советовал заморачиваться со scratch оргами. для 99% целей разработки они не нужны. Вот когда у вас все будет настроено как часы и проработает не менее пары лет, и вы поймете что чего-то не хватает что есть в теме scratch тогда можно попробовать и их. Пока советую про них забыть.

А, самое главное - почему в вашем случае (dev org -> sandbox -> git) 0 цена такого гит. Все коммиты будут идти от одного лица и в случае проблем нельзя будет найти виновного (того кто сломал). Можно будет узнать только когда сломали. А это очень важный момент - поиск виновных :))))) или доказательство своей невиновности :))))