Как вы деплоите в прод?

Есть еще Copado...

[quote="Den Brown"]Как вы деплоите в прод?[/quote]

Jenkins    
Но обычно вопрос не только чем но и что

На больших проектах (Enterprise) это тема обычно болезненная и сложная и берёт время выбрать, решить, настроить, обучить.
Решить какой Branch Strategy (например Feature Branch -> Dev 1-n -> Release 1-n -> Master), 
какие продукты использовать - то что уже есть или докупать
так как почти всегда есть несколько команд, каждая работает над своим модулем (Lead Management,  Sales, Service, ...) и в Production должны попасть в разное время (в зависимости от Release)
...

[quote="Eric"]Jenkins [/quote]

как это физически работает?

Jenkins в виде онлайн сервиса (или с твоего сервера, или с локальной машины?) по расписанию или "кликнув на кнопку" подключается к репо на гитхабе и деплоит на СФ орг?

Лучше всего деплоить на прод в виде managed package. Даже если это кастомизация. Так очень большой шанс что на проде никто без вашего ветода ничего не сломает.
А если unmanaged code то лучше чтобы это делал какой-нибудь deployment master (крайне отвественный человек). 
Jenkins хорошо, но он хорош для автоматизации деплоя на всякие DEV/UAT сандбоксы. Подключать прод к автоматизарованному деплою опасно. Не всегда деплой заходит хорошо. Иногда могут случаться косяки или требуются дополнительные шаги после деплоя. Конечно все это лучше оттестировать и настроить заранее в виде пост деплой скриптов. Но все равно деплой на прод штука отвественная и должна проходить вручную под контролем ответственного. 

Deploy в Прод - это всегда должно быть вручную, без автоматизации и для запланированного деплоя и для hot fix. 
Иногда такое же происходит и в QA
особенно если есть pre/post deployment steps (скрипты или manual steps)

[quote="Dmitry Shnyrev"] Не всегда деплой заходит хорошо. [/quote]Эххх мозоль мозоль...

Обычно этим занимаются люди которые релизят пакеты ;)

А кастомный код я последний раз деплоил только ручками через ченж сеты(Хотя это та еще боль).

[url=https://developer.salesforce.com/blogs/2020/08/new-salesforce-apex-circleci-orb.html?utm_campaign=SFDCNewsletter_September_2020&utm_medium=email&utm_source=newsletter&utm_medium=email]New Salesforce Apex CircleCI Orb[/url]

[quote="micha_s"][url=https://developer.salesforce.com/blogs/2020/08/new-salesforce-apex-circleci-orb.html?utm_campaign=SFDCNewsletter_September_2020&utm_medium=email&utm_source=newsletter&utm_medium=email]New Salesforce Apex CircleCI Orb[/url][/quote]
Что-то один в один как Bitbucket Pipelines помоему
UPD: хотя нет, в bitbucket pipelines нету возможности создавать новые орги(ну прям oob)

Не совсем понимаю я облачные решения по CI - смотрел несколько таких, все удобные, неплохие, но...очень дорогие с оплатой за каждый чих и оплата достаточно дорогая - в год на маленьком проекте под несколько тысяч долларов в год.
ИМХО в десятки раз дешевле поднять Jenkins в докере, настроить его там и не платить за то, что передеплоиваешь билд, потому что забыл ";" поставить или случайно забыл -meta файл закинуть. В довесок получаешь неограниченное количество бесплатных юзеров, отсутствие проблем со scalability и отсутствие platform-based проблем(например, одна из платформ не умела запускать валидацию PR с гитхаба).

[quote="EvAzi"]Не совсем понимаю я облачные решения по CI - смотрел несколько таких, все удобные, неплохие, но...очень дорогие с оплатой за каждый чих и оплата достаточно дорогая - в год на маленьком проекте под несколько тысяч долларов в год.
ИМХО в десятки раз дешевле поднять Jenkins в докере, настроить его там и не платить за то, что передеплоиваешь билд, потому что забыл ";" поставить или случайно забыл -meta файл закинуть. В довесок получаешь неограниченное количество бесплатных юзеров, отсутствие проблем со scalability и отсутствие platform-based проблем(например, одна из платформ не умела запускать валидацию PR с гитхаба).[/quote]

это потому что ты смотришь на это со стороны жадного пользователя

а те кто эти предложения делает смотрят со стороны жадной компании :)

[quote="EvAzi"]Jenkins в докере, настроить[/quote]
И на сервере развернуть.
Это мы дешевые рабы все можем делать сами чтобы сэкономить.
А в той же америкосии чел которые этим будет заниматься будет стоить 10к в месяц и при этом не разово чтобы поднять и настроить, а чтобы еще каждый месяц поддерживать. Вот и ХЗ что дешевле.

Вот к примеру, я могу поднять достаточно серьезный сервис на Heroku бесплатно, или на VPS от DO за 10$ в месяц вообще ракету в космос запустить. НО знаю проекты которые на инфраструктуру тратят десятки тысяч баксов в месяц  просто потому что не могу сделать нормально :D 

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

А еще есть такой один психологический фактор - цена продукта косвенно говорит (но не означает) что продукт крутой. Так и серьезные компании готовы платить дорого чтобы быть уверенными что все будет гуд.

[quote="Dmitry Shnyrev"]Лучше всего деплоить на прод в виде managed package. [/quote]

Согласен с таким подходом. Но если проект большой, то надо "разбивать" функционал на отдельные пакеты, чтобы ускорить процесс delivery и девелопмента. Как "разбить" логику на пакеты? По каким критериям разносить артифакты? Что делать с артифактами которые используються в нескольких пакетах(например обьекты)?

[quote="camamber"]Как "разбить" логику на пакеты? [/quote]
Ну это уже сугубо частный случай. Я не думаю что есть какие-то общие правила. 
Главное это не допустить одну большую ошибку - начать пилить БОЛЬШОЙ пакет, а потом понять что его можно было разделить на составные части. Увы, недостаток а скорее отсутствие долговременного планирования это обычная практика. Но суть это не меняет - на прод лучше managed package ставить, чтобы ни у кого не было соблазна взять и сломать все внезапно.

В моей картине CI/CD и DevOps для СФ всегда не хватало какого важного компонента, без которого все никак не складывалось в единый процесс.

в отличие от большинства других software разрабов, многие СФ разрабочики вполне могут спокойно жить и творить в тихом болотце из сендбоксов и чендж сетов и непонимающе морщиться при упоминании source-driven development.

наконец-то я увидел как организовать CI/CD и DevOps для СФ разработки минимальными средствами и усилиями.

переносишь project management  на (вроде как) бесплатный MS Azure DevOps (не путайте с MS Azure - если при регистрации вас спрашивают кретидку, то вы не там).

далее подключаешь к проекту свой ГитХаб. если при коммит комментах или пул-реквестах упоминаешь номер Таска в Azure DevOps Builboard, то на таске видны коммиты и прочее что случилось в ГитХабе по поводу этого таска.

Ну и самое главное это - Pipeline, которые позволяют автоматизировать задачи, которые в принципе выполнимы Shell командами.

Например, каждый мердж в мастер бренч в твоем ремоут репо на Гитхабе тригирует Pipeline, при которой:
- дается вирт машинка;
- (вроде как) в work directory уже находятся все компоненты из твоего мастер бренч;
- устанавливаешь sfdx cli;
- ну и далее делаешь что нужно, самое минимальное  - делаешь авторизацию и деплой мастер бренч в какой-то орге (где его уже обычно ждут QA). 

Т.е. какая-то обновка прилетела в мастер бренч, и - бум - она уже во всех оргах где это требуется.

Я еще только разбираюсь в теме, но как я понимаю, выполнение Pipeline скрипта можно организовать "ванильными" Shell командами, привлекая sfdx cli или совсем уж олд-скульно Ант, или использовать  Azure DevOps плагин для sfdx cli, который вроде как что-то упрощает, но пока не понятно, что и как.

Если знаете про MS Azure DevOps Pipeline и СФ что-то больше, чем я тут описал, то, пожалуйста, делитесь

Зачем тебе для Pipelines целый MS Azure DevOps?
Тоже самое работает прямо в Bitbucket.
https://bitbucket.org/product/ru/features/pipelines
Теже самые виртуальные машины поднимаются какие закажешь и позволяют запускать любые shell scripts. Прямо на git push срабатывают (настраивается гибко). Если совсем красиво хочется делать, то лучше сделать больше чем просто Pipelines и поднять полноценный CI (которых море платных и бесплатных).
Но вообще мы вроде недавно обсуждали - автоматический деплой на прод это зло и за это надо архитектору кое что отрезать. Максимум что можно автоматизировать с помощью CI/Pipelines это деплой на тестовые сандбоксы и запуст тестов, не более.

Но за совет про MS Azure DevOps спасибо - я не знал про него. Надо изучить, тем более пока занимают изучением .Net в целом :) 

[quote="Dmitry Shnyrev"]автоматический деплой на прод это зло[/quote]
Вернее я немного не так выразился. Деплой конечно должен быть автоматизирован - в смысле всякие скрипты валидации, компиляции и прочей лабуды (для SF конечно не особо актуально) должный быть, НО запускать весь этот зоопарк надо вручную по кнопке, а не по git push чтобы сработал pipeline. 

тема уже перешла  на то, как организовать (дешево и сердито) CI/CD и DevOps для СФ, без фокуса на деплой в Прод


про Pipelines в Bitbucket я не знал

выбор MS Azure DevOps был сделан очень просто, манагеры проекта увидели это в другом проекте и теперь им тоже так надо. Особенно им нравятся то, что на тасках-карточках видна связь с активностями на гите. Ну а если использовать в MS Azure DevOps его собственный Git remote repo service, то вообще все что надо для менеджмента проекта и CI/CD/DevOps находится в одном месте