Какие зависимости не попадают в Change Set автоматом?
Всем привет!
еще одна тема взятая прямо из жизни:
Какие компоненты не попадают в Change Set автоматом как необходимые зависимости? точнее сказать автоматом они в Change Set не попадают в любом случае, но появляются в специальной владке, что невероятно удобно.
у меня не указались:
- Табы, которые не закреплены в приложении, но участвиют в мобильном меню. - стат ресурсы - картинки, которые используются как иконки для actions.
Всем привет!
еще одна тема взятая прямо из жизни:
Какие компоненты не попадают в Change Set автоматом как необходимые зависимости?
точнее сказать автоматом они в Change Set не попадают в любом случае, но появляются в специальной владке, что невероятно удобно.
у меня не указались:
- Табы, которые не закреплены в приложении, но участвиют в мобильном меню.
- стат ресурсы - картинки, которые используются как иконки для actions.
что еще нужно не забыть проверить?
спасибо
Я бы сказал так - подход немного не верный.
Ты как программист должен знать все компоненты, которые входят в твое приложение (пакет) или должны быть включены в changeSet. Salesforce только помогает. В идеале ты вообще не должен пользоваться кнопкой показать зависимости.
Но все равно, согласен, мелочи обязательно забываются - не проблема, при deploy все всплывет А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.
Я бы сказал так - подход немного не верный.
Ты как программист должен знать все компоненты, которые входят в твое приложение (пакет) или должны быть включены в changeSet. Salesforce только помогает. В идеале ты вообще не должен пользоваться кнопкой показать зависимости.
Но все равно, согласен, мелочи обязательно забываются - не проблема, при deploy все всплывет :)
А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.
А теперь пример из моей практики. Салесфорс запретил нам пользоваться чендж сетами на проекте. У нас на проекте, сейчас порядка 14 дев сендбоксов и кучка Full сендбоксов. Обяснили это тем что в итоге потом концы не найдешь. Все крупные изменения делаем только через деплой из репозитория.
[quote="Dmitry Shnyrev"]Я бы сказал так - подход немного не верный.
Ты как программист должен знать все компоненты, которые входят в твое приложение (пакет) или должны быть включены в changeSet. Salesforce только помогает. В идеале ты вообще не должен пользоваться кнопкой показать зависимости.
Но все равно, согласен, мелочи обязательно забываются - не проблема, при deploy все всплывет :)
А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.[/quote]
А теперь пример из моей практики. Салесфорс запретил нам пользоваться чендж сетами на проекте. У нас на проекте, сейчас порядка 14 дев сендбоксов и кучка Full сендбоксов. Обяснили это тем что в итоге потом концы не найдешь. Все крупные изменения делаем только через деплой из репозитория.
не сразу понял, но понял. твоя ситуация была в том, что ты делал "дополнения" непосредственно к сущетсвующиему кастомному функционалу, и в зависимости указались те элементы, которые уже существуют в Проде, но от этого они не перестают быть зависимостями. И ты загрузил в ЧС и их. Буду иметь ввиду.
у меня проще. Это независимый от сущетсвующей кастомной структуры блок, поэтому все проще.
Вопрос у этой темы все-таки сугубо технический, к нему и вернусь: какие типы элементов в принципе (в силу каких то причин) не указываются в зависимостях при создании ЧС и поэтому их наличие стоит проверить особенно внимательно?
[quote="Dmitry Shnyrev"]
А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.[/quote]
не сразу понял, но понял. твоя ситуация была в том, что ты делал "дополнения" непосредственно к сущетсвующиему кастомному функционалу, и в зависимости указались те элементы, которые уже существуют в Проде, но от этого они не перестают быть зависимостями. И ты загрузил в ЧС и их. Буду иметь ввиду.
у меня проще. Это независимый от сущетсвующей кастомной структуры блок, поэтому все проще.
Вопрос у этой темы все-таки сугубо технический, к нему и вернусь: какие типы элементов в принципе (в силу каких то причин) не указываются в зависимостях при создании ЧС и поэтому их наличие стоит проверить особенно внимательно?
а где находится этот репозитарий?
в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?
[quote="wilder"] Все крупные изменения делаем только через деплой из репозитория.[/quote]
а где находится этот репозитарий?
в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?
спасибо
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию
[quote="Den Brown"][quote="wilder"] Все крупные изменения делаем только через деплой из репозитория.[/quote]
а где находится этот репозитарий?
в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?
спасибо[/quote]
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию
ок, в данном случае репозиторий - это не какой-то СФ-ный гит, специальный тул для работы c CФ, а "обычный" гит настроенный для работы с SF Оргом, и который может отгрузить в Орг метаданные также как например это делает Эклипс. И в связи с тем что в этом репозитарии находится только текущий рабочий код - то при перемещении метанных из Огра в Орг только он и попадает в Орг назначения без зацепа старых компонентов как зависимостей. И получается, что из репозитария можно отгрузить метаднные вкл юнит-тесты непосредственно в Прод?
[quote="wilder"]
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию[/quote]
ок, в данном случае репозиторий - это не какой-то СФ-ный гит, специальный тул для работы c CФ, а "обычный" гит настроенный для работы с SF Оргом, и который может отгрузить в Орг метаданные также как например это делает Эклипс.
И в связи с тем что в этом репозитарии находится только текущий рабочий код - то при перемещении метанных из Огра в Орг только он и попадает в Орг назначения без зацепа старых компонентов как зависимостей.
И получается, что из репозитария можно отгрузить метаднные вкл юнит-тесты непосредственно в Прод?
спасибо
Все крупные изменения делаем только через деплой из репозитория.
а где находится этот репозитарий?
в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?
спасибо
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию
Это именно так и работает. Только вместо выгрузки в прод обычно рспользуется препрод.
[quote="wilder"][quote="Den Brown"][quote="wilder"] Все крупные изменения делаем только через деплой из репозитория.[/quote]
а где находится этот репозитарий?
в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?
спасибо[/quote]
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию[/quote]
Это именно так и работает. Только вместо выгрузки в прод обычно рспользуется препрод.
Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.
А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?
[quote="wilder"]Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.[/quote]
А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?
Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.
А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?
тоже из репозитория. Препрод только для окончательной проверки, там ничего нельзя менять. Только проверка. Поэтому и пакет который ставится на препрод и прод будут одинаковые.
[quote="Dmitry Shnyrev"][quote="wilder"]Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.[/quote]
А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?[/quote]
тоже из репозитория. Препрод только для окончательной проверки, там ничего нельзя менять. Только проверка. Поэтому и пакет который ставится на препрод и прод будут одинаковые.
сегодня один контроллер не отгрузился в чендж-сет.
он уже есть в проде, я перенес его на прошлой неделе, сейчас я только добавил в нем одно поле в Select
и не отгрузился. пишет, что принимающий Орг должен быть версии не менее 31. Что за дела?
Ps: нашел как понизить API на классе. Но получается что за неделю API в сендбоксе автоматов повысился, а в Проде - нет.
сегодня один контроллер не отгрузился в чендж-сет.
он уже есть в проде, я перенес его на прошлой неделе, сейчас я только добавил в нем одно поле в Select
и не отгрузился. пишет, что принимающий Орг должен быть версии не менее 31. Что за дела?
Ps: нашел как понизить API на классе. Но получается что за неделю API в сендбоксе автоматов повысился, а в Проде - нет.
Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)
Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)
Вот здесь вроде можно проверить расписание перевода оргов на новую версию API
[url]https://trust.salesforce.com/trust/maintenance/[/url]
Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)
на части из них API подняли, на части нет. Собрал пакет на сандбоксе где стоит более высокая версия, и тут начинается веселуха. Поставить его не могу в другие сендбоксы потому что там более низкий АПИ. В общем пришлось кое что ручками править. И кто виноват в этом ? Я лично думаю что это косяк менеджеров салесфорса которые участвуют в проекте.
З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)
[quote="Dmitry Shnyrev"]Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)
Вот здесь вроде можно проверить расписание перевода оргов на новую версию API
[url]https://trust.salesforce.com/trust/maintenance/[/url][/quote]
Могу рассказать прикол. Проект 15 сандбоксов.
на части из них API подняли, на части нет. Собрал пакет на сандбоксе где стоит более высокая версия, и тут начинается веселуха. Поставить его не могу в другие сендбоксы потому что там более низкий АПИ. В общем пришлось кое что ручками править. И кто виноват в этом ? Я лично думаю что это косяк менеджеров салесфорса которые участвуют в проекте.
З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)
З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)
[quote]З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)[/quote]
))))))))))))))))) веселое наблюдение!