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

Обновление и загрузка пакетов после коммита кода в Git с помощью Ant

Есть орг, в котором разрабатывается пакет. Есть Git. И есть CircleCI, который собирает и запускает тесты.

Можно ли с помощью Ant (или еще что-то) обновить пакет (добавить новые компоненты из коммита или удалить) и загрузить его (в Salesforce), чтоб получить новый URL?


Обновление 1.
Задавайте правильно вопрос и не надо додумывать со своей стороны ничего. Это я про Metadata API.

Есть орг, в котором разрабатывается пакет. Есть Git. И есть CircleCI, который собирает и запускает тесты.

Можно ли с помощью Ant (или еще что-то) обновить пакет (добавить новые компоненты из коммита или удалить) и загрузить его (в Salesforce), чтоб получить новый URL?


Обновление 1.
Задавайте правильно вопрос и не надо додумывать со своей стороны ничего. Это я про Metadata API.

В автоматическом режиме не видел. Но можно написать скрипт который это сделает.

В автоматическом режиме не видел. Но можно написать скрипт который это сделает.

Можно Антом обновить пакет.

package.xml

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<fullName>DevMuza</fullName>
<apiAccessLevel>Unrestricted</apiAccessLevel>
<description>DevMuza Package to test CircleCI.</description>
<namespacePrefix>dev_muza</namespacePrefix>
<types>
<members>ContactCounter_Ext</members>
<members>ContactCounter_Ext_UT</members>
<name>ApexClass</name>
</types>
<types>
<members>CountContacts</members>
<name>ApexPage</name>
</types>
<types>
<members>Account.Number_of_Contacts__c</members>
<name>CustomField</name>
</types>
<version>40.0</version>
</Package>


build.xml

<target name="updatePkg">
<sf:deploy username="${sf.username}" password="${sf.password}" sessionId="${sf.sessionId}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" deployRoot="src" />
</target>


-- build.properties
-- build.xml
-- src
--- classes
--- objects
--- pages
--- package.xml

Можно Антом обновить пакет.

package.xml
[code]<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>DevMuza</fullName>
    <apiAccessLevel>Unrestricted</apiAccessLevel>
    <description>DevMuza Package to test CircleCI.</description>
    <namespacePrefix>dev_muza</namespacePrefix>
    <types>
        <members>ContactCounter_Ext</members>
        <members>ContactCounter_Ext_UT</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>CountContacts</members>
        <name>ApexPage</name>
    </types>
    <types>
        <members>Account.Number_of_Contacts__c</members>
        <name>CustomField</name>
    </types>
    <version>40.0</version>
</Package>
[/code]


build.xml
[code]<target name="updatePkg">
      <sf:deploy username="${sf.username}" password="${sf.password}" sessionId="${sf.sessionId}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" deployRoot="src" />
    </target>[/code]


-- build.properties
-- build.xml
-- src
--- classes
--- objects
--- pages
--- package.xml

Чет не понял.
Таким простым способом, ты обновляешь пакет (добавляешь/изменяешь компоненты включенные в пакет) и потом заставляешь сгенерировать новую версию пакета (чтобы получить новый URL для установки как ты писал в вопросе)?

Чет не понял. 
Таким простым способом, ты обновляешь пакет (добавляешь/изменяешь компоненты включенные в пакет) и потом заставляешь сгенерировать новую версию пакета (чтобы получить новый URL для установки как ты писал в вопросе)?

Да, этим простым способом я обновляю сам пакет. Не просто компоненты в орге, а именно включение компонентов в пакет. Т.к., если у тебя класс не был включен в пакет, то после этой загрузки (deploy) он будет включен.

До генерирования новой версии не дошел. Там надо чет придумать с получением нового Id. Это план на сегодня/завтра. Я до обновить компоненты шел 3-4 дня :-)
Правда, я не пробовал деструктивный вариант, когда удаляешь че-нить. Пока мне это не надо и я не хочу пока на это тратить время.

Новый урл - это Id пакета. Когда пакет загрузился, тебе вернется его Id. Этот Id подставляешь в https://login.salesforce.com/packaging/installPackage.apexp?p0=ИдПакета и все. Сгенерил новую версию - получи новый Id. У меня сейчас пару версий одного пакета. Так можно взять любой Id и установить.

Да, этим простым способом я обновляю сам пакет. Не просто компоненты в орге, а именно включение компонентов в пакет. Т.к., если у тебя класс не был включен в пакет, то после этой загрузки (deploy) он будет включен.

До генерирования новой версии не дошел. Там надо чет придумать с получением нового Id. Это план на сегодня/завтра. Я до обновить компоненты шел 3-4 дня :-)
Правда, я не пробовал деструктивный вариант, когда удаляешь че-нить. Пока мне это не надо и я не хочу пока на это тратить время.

Новый урл - это Id пакета. Когда пакет загрузился, тебе вернется его Id. Этот Id подставляешь в https://login.salesforce.com/packaging/installPackage.apexp?p0=ИдПакета и все. Сгенерил новую версию - получи новый Id. У меня сейчас пару версий одного пакета. Так можно взять любой Id и установить.

Кстати на счет удаления из пакета.
С этим будь осторожнее. Нельзя ничего удалить из пакета после упаковки релизной версия (или как там она правильно называется, в общем не та что beta) (можно вроде только через службу поддержки и то наверное только в виде исключения). Наверное поэтому не предусмотрено таких простых способов чтобы накидать в пакет всякой фигни. Лучше добавлять элемент в пакет один раз, и осознанно, руками.

Кстати на счет удаления из пакета.
С этим будь осторожнее. Нельзя ничего удалить из пакета после упаковки релизной версия (или как там она правильно называется, в общем не та что beta) (можно вроде только через службу поддержки и то наверное только в виде исключения). Наверное поэтому не предусмотрено таких простых способов чтобы накидать в пакет всякой фигни. Лучше добавлять элемент в пакет один раз, и осознанно, руками.

Посмотрим. Но помимо изменения содержимого пакета его еще надо загрузить. Managed Package можно, вроде, принудительно (push) загрузить всем, у кого он сейчас установлен.
А так, обновление компонентов в пакете - это еще не изменение последней версии пакета.

Посмотрим. Но помимо изменения содержимого пакета его еще надо загрузить. Managed Package можно, вроде, принудительно (push) загрузить всем, у кого он сейчас установлен.
А так, обновление компонентов в пакете - это еще не изменение последней версии пакета.

А зачем "принудительно" всем грузить?
Я конечно за автоматическое обновление, но не думаю что все будут рады.
Скажем я взял твой пакет и пилю интеграции для него (очень часто такое бывает на SF). А ты такой бац и прислал мне обновление которое сломало мне всю интеграцию. И что самое интересно ХЗ откуда ноги выросли в такой момент. Вчера работало а сегодня нет. Почему? Мистика!

А зачем "принудительно" всем грузить?
Я конечно за автоматическое обновление, но не думаю что все будут рады.
Скажем я взял твой пакет и пилю интеграции для него (очень часто такое бывает на SF). А ты такой бац и прислал мне обновление которое сломало мне всю интеграцию. И что самое интересно ХЗ откуда ноги выросли в такой момент. Вчера работало а сегодня нет. Почему? Мистика!

Dmitry Shnyrev
А зачем "принудительно" всем грузить?
Я конечно за автоматическое обновление, но не думаю что все будут рады.
Скажем я взял твой пакет и пилю интеграции для него (очень часто такое бывает на SF). А ты такой бац и прислал мне обновление которое сломало мне всю интеграцию. И что самое интересно ХЗ откуда ноги выросли в такой момент. Вчера работало а сегодня нет. Почему? Мистика!

Ну, вдруг там какая уязвимость.
Понятно, что принципиально что-то менять никто не будет (как пример, принудительный запрет TLS 1.0). Но устранить какую-нить уязвимость, почему бы и нет.

[quote="Dmitry Shnyrev"]А зачем "принудительно" всем грузить?
Я конечно за автоматическое обновление, но не думаю что все будут рады.
Скажем я взял твой пакет и пилю интеграции для него (очень часто такое бывает на SF). А ты такой бац и прислал мне обновление которое сломало мне всю интеграцию. И что самое интересно ХЗ откуда ноги выросли в такой момент. Вчера работало а сегодня нет. Почему? Мистика![/quote]
Ну, вдруг там какая уязвимость.
Понятно, что принципиально что-то менять никто не будет (как пример, принудительный запрет TLS 1.0). Но устранить какую-нить уязвимость, почему бы и нет.

Вот такой косвенный пример сегодня - срусь со службой поддержки Assistent.by.
Они такие взяли и добавили валидацию на номер банковского счета для контрагентов (клиентов). Я 2 года работаю без проблем. А сегодня хочу добавить поступление и хер. Пишет "выберите контрагента из списка". А он сука выбран. Короче писал, пытался звонить. Полный игнор. Благо я сам программист и знаю как не в первой самому разбираться в чужих косяках. В поисках вышел на форму создания контрагентов, пытаюсь пересохранить старого контрагента, а мне "номер счета невалидный". Что значит невалидный? Мне его прислал сам заказчик. Он в договоре есть. Я же не поеду другую страну проверять какой там у них формат. А бляцки Assistent.by знает какой должен быть формат! Даже знает какой должен быть формат в Перу и Папуа Новая Гвинея!!! Вот черти, реально подготовились чтобы добавить такую валидацию!

Это я к тому, что не каждый будет рад автоматическому обновлению приложения если оно вдруг сломается или что-то сломает!

Вот такой косвенный пример сегодня - срусь со службой поддержки [b]Assistent.by[/b].
Они такие взяли и добавили валидацию на номер банковского счета для контрагентов (клиентов). Я 2 года работаю без проблем. А сегодня хочу добавить поступление и хер. Пишет "выберите контрагента из списка". А он сука выбран. Короче писал, пытался звонить. Полный игнор. Благо я сам программист и знаю как не в первой самому разбираться в чужих косяках. В поисках вышел на форму создания контрагентов, пытаюсь пересохранить старого контрагента, а мне "номер счета невалидный". Что значит невалидный? Мне его прислал сам заказчик. Он в договоре есть. Я же не поеду другую страну проверять какой там у них формат. А бляцки Assistent.by знает какой должен быть формат! Даже знает какой должен быть формат в Перу и Папуа Новая Гвинея!!! Вот черти, реально подготовились чтобы добавить такую валидацию!

Это я к тому, что не каждый будет рад автоматическому обновлению приложения если оно вдруг сломается или что-то сломает! 

А что значит устранить уязвивость? Ты знаешь как избирательно производить апдейты пакетов?
Если у одного стоит скажем 10 версия, у другого 20, а ты сделал критический фикс в 30. Что ты зальешь клиентам?

А что значит устранить уязвивость? Ты знаешь как избирательно производить апдейты пакетов?
Если у одного стоит скажем 10 версия, у другого 20, а ты сделал критический фикс в 30. Что ты зальешь клиентам?

Можно конечно делать патчи под каждую отдельную версию. Но что-то я сомневаюсь что это кто-то сможет реализовать на должном уровне. Видел один раз попытку работы с патчами. Без слез не обойтись

Можно конечно делать патчи под каждую отдельную версию. Но что-то я сомневаюсь что это кто-то сможет реализовать на должном уровне. Видел один раз попытку работы с патчами. Без слез не обойтись :D 

Я хз, я еще до этого не дошел :-)

Я хз, я еще до этого не дошел :-)

А что ты такой пилишь? В общих чертах если не секрет?

Andrew Muzychuk
Есть орг, в котором разрабатывается пакет. Есть Git. И есть CircleCI, который собирает и запускает тесты.

Если занимаешься организацией дев процессов, то лучше не связывать CI с самим пакетом. Сколько я видел реализаций. Обычно делалось так.
Брался Git к нему прикручивался CI + тестовый орг. Все автоматизация была закручена на этом.
Каждый деплой в Git триггерил CI и тот заливал код на тестовый орг и запускал тесты.
Нигде тут даже и близко не пахло пакетом. Потому что в CI попадало очень много всего лишнего, что потом спокойно убиралось/фиксилось.

А уже в назначенный час Ч приходил "главный" и на сливал Git на отдельный пакетный орг и собирал все вручную. Так релиз собирался раз в 2 недели или раз в месяц. Но Git+CI+тестовый орг пыхтели постоянно! И это пыхтение совсем не касалось пакета.

А что ты такой пилишь? В общих чертах если не секрет?
[quote="Andrew Muzychuk"]Есть орг, в котором разрабатывается пакет. Есть Git. И есть CircleCI, который собирает и запускает тесты.[/quote]
Если занимаешься организацией дев процессов, то лучше не связывать CI с самим пакетом. Сколько я видел реализаций. Обычно делалось так.
Брался Git к нему прикручивался CI + тестовый орг. Все автоматизация была закручена на этом.
Каждый деплой в Git триггерил CI и тот заливал код на тестовый орг и запускал тесты.
Нигде тут даже и близко не пахло пакетом. Потому что в CI попадало очень много всего лишнего, что потом спокойно убиралось/фиксилось.

А уже в назначенный час Ч приходил "главный" и на сливал Git на отдельный пакетный орг и собирал все вручную. Так релиз собирался раз в 2 недели или раз в месяц. Но Git+CI+тестовый орг пыхтели постоянно! И это пыхтение совсем не касалось пакета.

Сам пакет прост. У товарищей Visualforce страница, на которой отображается информация из их сервиса на основе объекта в СФ. Эта страница используется в секции деталей объекта в стандартном лэйаут (layout; как его нормально на русском назвать я хз).
Сейчас для того, чтобы это было у клиента надо пройти целую инструкцию по созданию компоненты, страницы, полей на объектах и, наконец, добавление страницы в детали объекта как секцию.
Я сделал в пакете все это и теперь надо только установить пакет и добавить секцию в детали объекта.

Пока у меня CI сделан просто. В master я сразу скидываю то, что должно быть в пакете. У меня ничего лишнего в орге нет, только то, что для пакета. Доделаю загрузку пакета и получение нового Id, тогда сделаю прогон тестов на другом (чистом) орге (хоть это реально 1 час делов).

Сам пакет прост. У товарищей Visualforce страница, на которой отображается информация из их сервиса на основе объекта в СФ. Эта страница используется в секции деталей объекта в стандартном лэйаут (layout; как его нормально на русском назвать я хз).
Сейчас для того, чтобы это было у клиента надо пройти целую инструкцию по созданию компоненты, страницы, полей на объектах и, наконец, добавление страницы в детали объекта как секцию.
Я сделал в пакете все это и теперь надо только установить пакет и добавить секцию в детали объекта.

Пока у меня CI сделан просто. В master я сразу скидываю то, что должно быть в пакете. У меня ничего лишнего в орге нет, только то, что для пакета. Доделаю загрузку пакета и получение нового Id, тогда сделаю прогон тестов на другом (чистом) орге (хоть это реально 1 час делов).

Я так понял ты в свой пакет добавил стандратный layout. Я конечно в этой теме не очень, но разве при установке пакет не выдаст ошибку что такой layout есть? Или же обновит используемый стандартный? Или все таки добовляешь свой layout, который клиент может испоользовать?

Я так понял ты в свой пакет добавил стандратный layout. Я конечно в этой теме не очень, но разве при установке пакет не выдаст ошибку что такой layout есть? Или же обновит используемый стандартный? Или все таки добовляешь свой layout, который клиент может испоользовать?

Я пробовал добавлять layout. При установке пакета создается packageNamespace_layoutName. Ничего не перезапишется. Может Unmanaged Package такое сделает, но не Managed Package.
Я думал подшаманить это с помощью API, но такое может не понравиться пользователям. Так что, куда запихивать страничку-секцию было решено отдать пользователям/админам.

Я пробовал добавлять layout. При установке пакета создается packageNamespace_layoutName. Ничего не перезапишется. Может Unmanaged Package такое сделает, но не Managed Package.
Я думал подшаманить это с помощью API, но такое может не понравиться пользователям. Так что, куда запихивать страничку-секцию было решено отдать пользователям/админам.