Какие зависимости не попадают в Change Set автоматом?
Всем привет!
еще одна тема взятая прямо из жизни:
Какие компоненты не попадают в Change Set автоматом как необходимые зависимости? точнее сказать автоматом они в Change Set не попадают в любом случае, но появляются в специальной владке, что невероятно удобно.
у меня не указались:
- Табы, которые не закреплены в приложении, но участвиют в мобильном меню. - стат ресурсы - картинки, которые используются как иконки для actions.
Ты как программист должен знать все компоненты, которые входят в твое приложение (пакет) или должны быть включены в changeSet. Salesforce только помогает. В идеале ты вообще не должен пользоваться кнопкой показать зависимости.
Но все равно, согласен, мелочи обязательно забываются - не проблема, при deploy все всплывет А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.
А теперь пример из моей практики. Салесфорс запретил нам пользоваться чендж сетами на проекте. У нас на проекте, сейчас порядка 14 дев сендбоксов и кучка Full сендбоксов. Обяснили это тем что в итоге потом концы не найдешь. Все крупные изменения делаем только через деплой из репозитория.
не сразу понял, но понял. твоя ситуация была в том, что ты делал "дополнения" непосредственно к сущетсвующиему кастомному функционалу, и в зависимости указались те элементы, которые уже существуют в Проде, но от этого они не перестают быть зависимостями. И ты загрузил в ЧС и их. Буду иметь ввиду.
у меня проще. Это независимый от сущетсвующей кастомной структуры блок, поэтому все проще.
Вопрос у этой темы все-таки сугубо технический, к нему и вернусь: какие типы элементов в принципе (в силу каких то причин) не указываются в зависимостях при создании ЧС и поэтому их наличие стоит проверить особенно внимательно?
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию
ок, в данном случае репозиторий - это не какой-то СФ-ный гит, специальный тул для работы c CФ, а "обычный" гит настроенный для работы с SF Оргом, и который может отгрузить в Орг метаданные также как например это делает Эклипс. И в связи с тем что в этом репозитарии находится только текущий рабочий код - то при перемещении метанных из Огра в Орг только он и попадает в Орг назначения без зацепа старых компонентов как зависимостей. И получается, что из репозитария можно отгрузить метаднные вкл юнит-тесты непосредственно в Прод?
Все крупные изменения делаем только через деплой из репозитория.
а где находится этот репозитарий?
в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?
спасибо
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию
Это именно так и работает. Только вместо выгрузки в прод обычно рспользуется препрод.
Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.
А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?
тоже из репозитория. Препрод только для окончательной проверки, там ничего нельзя менять. Только проверка. Поэтому и пакет который ставится на препрод и прод будут одинаковые.
Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)
Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)
на части из них API подняли, на части нет. Собрал пакет на сандбоксе где стоит более высокая версия, и тут начинается веселуха. Поставить его не могу в другие сендбоксы потому что там более низкий АПИ. В общем пришлось кое что ручками править. И кто виноват в этом ? Я лично думаю что это косяк менеджеров салесфорса которые участвуют в проекте.
З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)
З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)