Регистрация  |  Вход

Какие зависимости не попадают в Change Set автоматом?

Всем привет!

еще одна тема взятая прямо из жизни:

Какие компоненты не попадают в Change Set автоматом как необходимые зависимости?
точнее сказать автоматом они в Change Set не попадают в любом случае, но появляются в специальной владке, что невероятно удобно.

у меня не указались:

- Табы, которые не закреплены в приложении, но участвиют в мобильном меню.
- стат ресурсы - картинки, которые используются как иконки для actions.

что еще нужно не забыть проверить?

спасибо

Всем привет!

еще одна тема взятая прямо из жизни:

Какие компоненты не попадают в Change Set автоматом как необходимые зависимости?
точнее сказать автоматом они в Change Set не попадают в любом случае, но появляются в специальной владке, что невероятно удобно.

у меня не указались:

- Табы, которые не закреплены в приложении, но участвиют в мобильном меню.
- стат ресурсы - картинки, которые используются как иконки для actions.

что еще нужно не забыть проверить?

спасибо

Я бы сказал так - подход немного не верный.

Ты как программист должен знать все компоненты, которые входят в твое приложение (пакет) или должны быть включены в changeSet. Salesforce только помогает. В идеале ты вообще не должен пользоваться кнопкой показать зависимости.

Но все равно, согласен, мелочи обязательно забываются - не проблема, при deploy все всплывет
А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.

Я бы сказал так - подход немного не верный.

Ты как программист должен знать все компоненты, которые входят в твое приложение (пакет) или должны быть включены в changeSet. Salesforce только помогает. В идеале ты вообще не должен пользоваться кнопкой показать зависимости.

Но все равно, согласен, мелочи обязательно забываются - не проблема, при deploy все всплывет :)

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

Dmitry Shnyrev
Я бы сказал так - подход немного не верный.

Ты как программист должен знать все компоненты, которые входят в твое приложение (пакет) или должны быть включены в changeSet. Salesforce только помогает. В идеале ты вообще не должен пользоваться кнопкой показать зависимости.

Но все равно, согласен, мелочи обязательно забываются - не проблема, при deploy все всплывет
А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.

А теперь пример из моей практики. Салесфорс запретил нам пользоваться чендж сетами на проекте. У нас на проекте, сейчас порядка 14 дев сендбоксов и кучка Full сендбоксов. Обяснили это тем что в итоге потом концы не найдешь. Все крупные изменения делаем только через деплой из репозитория.

[quote="Dmitry Shnyrev"]Я бы сказал так - подход немного не верный.

Ты как программист должен знать все компоненты, которые входят в твое приложение (пакет) или должны быть включены в changeSet. Salesforce только помогает. В идеале ты вообще не должен пользоваться кнопкой показать зависимости.

Но все равно, согласен, мелочи обязательно забываются - не проблема, при deploy все всплывет :)

А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.[/quote]

А теперь пример из моей практики. Салесфорс запретил нам пользоваться чендж сетами на проекте. У нас на проекте, сейчас порядка 14 дев сендбоксов и кучка Full сендбоксов. Обяснили это тем что в итоге потом концы не найдешь. Все крупные изменения делаем только через деплой из репозитория.

Dmitry Shnyrev
А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.

не сразу понял, но понял. твоя ситуация была в том, что ты делал "дополнения" непосредственно к сущетсвующиему кастомному функционалу, и в зависимости указались те элементы, которые уже существуют в Проде, но от этого они не перестают быть зависимостями. И ты загрузил в ЧС и их. Буду иметь ввиду.

у меня проще. Это независимый от сущетсвующей кастомной структуры блок, поэтому все проще.

Вопрос у этой темы все-таки сугубо технический, к нему и вернусь: какие типы элементов в принципе (в силу каких то причин) не указываются в зависимостях при создании ЧС и поэтому их наличие стоит проверить особенно внимательно?

[quote="Dmitry Shnyrev"]
А по поводу зависимостей - есть очень интересный "негативный" пример из жизни. Мне поставили задачу собрать changeSet на новом для меня проекте. Там получилось около 400 элементов. Ну я то что знал включил, остальное все подтянул через зависимости. А заказчик, вернее их админ попался правильный - проверил все элементы которые я включил. Нам пришлось потом долго краснеть и объяснять какого ... мы включили в наш changeSet их собственный кусок функционала, который к нам никакого отношения не имел. Так что будь аккуратнее.[/quote]

не сразу понял, но понял. твоя ситуация была в том, что ты делал "дополнения" непосредственно к сущетсвующиему кастомному функционалу, и в зависимости указались те элементы, которые уже существуют в Проде, но от этого они не перестают быть зависимостями. И ты загрузил в ЧС и их. Буду иметь ввиду.

у меня проще. Это независимый от сущетсвующей кастомной структуры блок, поэтому все проще.

Вопрос у этой темы все-таки сугубо технический, к нему и вернусь: какие типы элементов в принципе (в силу каких то причин) не указываются в зависимостях при создании ЧС и поэтому их наличие стоит проверить особенно внимательно?

wilder
Все крупные изменения делаем только через деплой из репозитория.

а где находится этот репозитарий?

в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?

спасибо

[quote="wilder"] Все крупные изменения делаем только через деплой из репозитория.[/quote]

а где находится этот репозитарий?

в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?

спасибо

Den Brown
wilder
Все крупные изменения делаем только через деплой из репозитория.

а где находится этот репозитарий?

в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?

спасибо

Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию

[quote="Den Brown"][quote="wilder"] Все крупные изменения делаем только через деплой из репозитория.[/quote]

а где находится этот репозитарий?

в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?

спасибо[/quote]

Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию

wilder
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию

ок, в данном случае репозиторий - это не какой-то СФ-ный гит, специальный тул для работы c CФ, а "обычный" гит настроенный для работы с SF Оргом, и который может отгрузить в Орг метаданные также как например это делает Эклипс.
И в связи с тем что в этом репозитарии находится только текущий рабочий код - то при перемещении метанных из Огра в Орг только он и попадает в Орг назначения без зацепа старых компонентов как зависимостей.
И получается, что из репозитария можно отгрузить метаднные вкл юнит-тесты непосредственно в Прод?

спасибо

[quote="wilder"]
Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию[/quote]

ок, в данном случае репозиторий - это не какой-то СФ-ный  гит, специальный тул для работы c CФ, а "обычный" гит настроенный для работы с SF Оргом, и который может отгрузить в Орг метаданные также как например это делает Эклипс.
И в связи с тем что в этом репозитарии находится только текущий рабочий код - то при перемещении метанных из Огра в Орг только он и попадает в Орг назначения без зацепа старых компонентов как зависимостей.
И получается, что из репозитария можно отгрузить метаднные вкл юнит-тесты непосредственно в Прод?

спасибо

wilder
Den Brown
wilder
Все крупные изменения делаем только через деплой из репозитория.

а где находится этот репозитарий?

в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?

спасибо

Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию

Это именно так и работает. Только вместо выгрузки в прод обычно рспользуется препрод.

[quote="wilder"][quote="Den Brown"][quote="wilder"] Все крупные изменения делаем только через деплой из репозитория.[/quote]

а где находится этот репозитарий?

в чем процесс переноса метаданных через него отличается (и поэтому в некоторых случаям, как видно, предпочтительнее) от переноса через ЧСеты?

спасибо[/quote]

Репозиторий это гит или его производные. Соответственно для гита есть много разных утилит в которых можно делать мержи по бренчам и прочую синхронизацию[/quote]

Это именно так и работает. Только вместо выгрузки в прод обычно рспользуется препрод.

wilder
Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.

А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?

[quote="wilder"]Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.[/quote]

А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?

Dmitry Shnyrev
wilder
Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.

А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?

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

[quote="Dmitry Shnyrev"][quote="wilder"]Это именно так и работает. Только вместо выгрузки в прод обычно используется препрод.[/quote]

А из предпрода на прод как переносите? уже changeSet или тоже из репозитория?[/quote]

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

сегодня один контроллер не отгрузился в чендж-сет.

он уже есть в проде, я перенес его на прошлой неделе, сейчас я только добавил в нем одно поле в Select

и не отгрузился. пишет, что принимающий Орг должен быть версии не менее 31. Что за дела?

Ps: нашел как понизить API на классе. Но получается что за неделю API в сендбоксе автоматов повысился, а в Проде - нет.

сегодня один контроллер не отгрузился в чендж-сет.

он уже есть в проде, я перенес его на прошлой неделе, сейчас я только добавил в нем одно поле в Select

и не отгрузился. пишет, что принимающий Орг должен быть версии не менее 31. Что за дела?

Ps: нашел как понизить API на классе. Но получается что за неделю API в сендбоксе автоматов повысился, а в Проде - нет.

Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)

Вот здесь вроде можно проверить расписание перевода оргов на новую версию API
https://trust.salesforce.com/trust/maintenance/

Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)

Вот здесь вроде можно проверить расписание перевода оргов на новую версию API
[url]https://trust.salesforce.com/trust/maintenance/[/url]

Dmitry Shnyrev
Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)

Вот здесь вроде можно проверить расписание перевода оргов на новую версию API
https://trust.salesforce.com/trust/maintenance/

Могу рассказать прикол. Проект 15 сандбоксов.

на части из них API подняли, на части нет. Собрал пакет на сандбоксе где стоит более высокая версия, и тут начинается веселуха. Поставить его не могу в другие сендбоксы потому что там более низкий АПИ. В общем пришлось кое что ручками править. И кто виноват в этом ? Я лично думаю что это косяк менеджеров салесфорса которые участвуют в проекте.

З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)

[quote="Dmitry Shnyrev"]Это нормально. Прод и Сандбоксы могут быть физически и территориально разнесены и обновляться в разное время. Тем более логика подсказывает что сперва лучше обновить сандбоксы, посмотреть чтобы все не упало, а затем проды (что по ходу и делает SF)

Вот здесь вроде можно проверить расписание перевода оргов на новую версию API
[url]https://trust.salesforce.com/trust/maintenance/[/url][/quote]

Могу рассказать прикол. Проект 15 сандбоксов.

на части из них API подняли, на части нет. Собрал пакет на сандбоксе где стоит более высокая версия, и тут начинается веселуха. Поставить его не могу в другие сендбоксы потому что там более низкий АПИ. В общем пришлось кое что ручками править. И кто виноват в этом ? Я лично думаю что это косяк менеджеров салесфорса которые участвуют в проекте. 

З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)

З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)

))))))))))))))))) веселое наблюдение!

[quote]З.Ы. Если у человека есть какие-то сертификаты, это еще не значит что он хороший специалист, есть вероятность что он просто хорошо знает английский язык :)[/quote]

)))))))))))))))))   веселое наблюдение!