Кнопка "Вернуть все как было"

Абсолютная правда. При внедрении CI все только про авто деплой и авто откат и думают. 
НО на своей практике никогда не видел чтобы автооткат использовался. И как раз по этой самой причине - что нихрена нормально не откатится даже уже на этапе прогнозирования. Поэтому если что-то сломалось, просто делается новый следующий коммит который просто дизейблит/комитит/фиксит неудавшуюся часть кода. То есть движение всегда только вперед, никогда назад!!!! :party: 

ok, ждем что [b]wilder[/b] добавит к уже сказанному и выше изложенному

[quote="Den Brown"]Как вы знаете, при DevOps - CI/CD подходе метадата грузится в Прод (или в При-прод) из соответствующей ветки в VCS, и менеджеры думают, что одно из преимуществ такого подхода - это наличие некой кнопка "[i]Вернуть все как было[/i]", т.е. в случае деплоя в стиле "Наташа, мы все сломали", то можно нажать на эту кнопку и все в Проде вернется, как было до деплоя.

Но правда ли это? 

На уровне VCS - да, можно так или иначе сделать roll-back, и ветка вернется к прежнему state, но поможет ли это вернуть "все как было" в самом Орге? Что если плохой деплой включал создание новых классов, новых объектов? Если сделать roll-back на ветке и потом попробовать деплойнуть ее, то что с ними будет? во многих случаях без их удаления и вернуться ко "все как было" не получится, так как там все зависимости-зависимости...[/quote]

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

произойдет следующее : так то если изменения в xml file, тот же например workflow или field задеплоишь, потом передумаешь и решишь откатить то деплой пустого workflow файла, или отсутствия поля и т.д. ни к чему не приведет, даже деплой пустого workflow файла не удаляет (и никак не меняет) уже задеплоенные workflow на этом же обьекте в проде
В СФ чтобы откатить надо отдельно откатывать версии (типа изменения существующего класса) и отдельно откатывать полностью новые изменения типа нового поля. Для этого создается destructive.xml и туда вписывается что удалять, т.е. чтобы откатить надо проделать работу и не малую. 

Особенно если например был деплой, мы накатили изменения в схеме, новые поля, новые lwc и новый apex. потом задеплоили destructive и почистили/поудаляли старые поля на которые ссылался старый код который был изменен в релизе. И потом оно не работает. Ну вот это все задолбешься откатывать. Физически это возможно (в несколько деплоев, в 1 невозможно) но на практике так никто не делает и как сказал Дима просто движемся вперед.

вообще по нормальному создается кастом метадата с feature flag и у новых фичей создается флаг для выключения если мега баг. Старый функционал сломанный чинится в срочном порядке. Всё
а да CI/CD всяко надо иметь :smiley: 

К сожалению, я так грааля и не нашел в этом вопросе. Могу лишь посоветовать что-то в этом вопросе

1. Весь custom development должен быть упакован в unmanaged package
2. Это должен быть second generation package. И да из него можно удалять метадату
3. Пакет ставить нужно сначала ТОЛЬКО на sandbox

Открыт для дополнений и исправлений:)

[quote="wilder"]Весь custom development должен быть упакован в unmanaged package[/quote]
Хочу подчеркнуть данный пункт и добавить - делать managed package ТОЛЬКО в случае крайней необходимости. Реальный пример последнего клиента - изначально сделали managed package при том что кастомизация исключительно "для себя". но потом новый функционал начали делать как unmanaged code. Разработка между первым и вторым как небо и земля. Теперь стоит вопрос как избавиться от пакета и сделать все unmanaged. Я честно признаюсь тоже раньше не придавал этому значения и для меня что пилить managed что unmanaged code было равнозначным, но благодаря этому клиенту для себя открыл эту мудрость. Может кому пригодится на будущее. Но готов также выслушать аргументы против :smiley:

Вот и меня постиг данный проблем :sad:

Создал два объекта с M-D связью и Roll-up полем. И теперь не могу удалить child объект

This custom object is summarized by a field in another object. Remove the usage and try again.

И пофиг что поля уже давно нет :sad:

Шо рабить хз. Может через время кэш какой почистится, но пока все встало!

От млин! Я тупой!!! Совсем забыл про Deleted Fields :rolling:
В классике они лежали внизу списка и мозолили глаза, а в Lightning вынесены на отдельную страницу. Совсем забыл что удаление поля двухступенчатая процедура :party: