Deploy - некоторые мысли

Полная очистка орга предусмотрена перед деплоем?

[quote="Dmitry Shnyrev"]Полная очистка орга предусмотрена перед деплоем?[/quote]

Из моей практики это не так часто нужно. Да я пока и не сильно представляю как это корректно сделать.

[quote="wilder"]Дано репозиторий и таргет орг.

1. Деплой нужно делать с репозитория по :
 - триггеру
 - мануально
 - расписанию

2. Деплой может быть :
 - полный
 - дельта

3. Автоматическое формирование package.xml

4. Запуск скриптов
 - пост деплой
 - пре деплой

5. Запуск destructiveChanges

Что я еще забыл ?[/quote]
Синхронизация 2 оргов, как подзадача.

[quote="Gres"]Синхронизация 2 оргов, как подзадача.[/quote]

Синхронизация или сравнение ?

[quote="wilder"][quote="Gres"]Синхронизация 2 оргов, как подзадача.[/quote]

Синхронизация или сравнение ?[/quote]
Я не знаю какаю модель разработки и хранения ты будешь использовать.
У меня, например, сравнение делает git, а синхронизацию уже мой билд скрипт.
Всегда нужно исходить из юзкейсов. Для меня, например, актуален бэкап орга и деплой, удаление измененных файлов.
Можем обсудить эти вещи, если интересно.

[quote="Gres"][quote="wilder"][quote="Gres"]Синхронизация 2 оргов, как подзадача.[/quote]

Синхронизация или сравнение ?[/quote]
Я не знаю какаю модель разработки и хранения ты будешь использовать.
У меня, например, сравнение делает git, а синхронизацию уже мой билд скрипт.
Всегда нужно исходить из юзкейсов. Для меня, например, актуален бэкап орга и деплой, удаление измененных файлов.
Можем обсудить эти вещи, если интересно.[/quote]

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

[quote="wilder"][quote="Dmitry Shnyrev"]Полная очистка орга предусмотрена перед деплоем?[/quote]

Из моей практики это не так часто нужно. Да я пока и не сильно представляю как это корректно сделать.[/quote]
Знаешь, я сейчас столкнулся в разработке с правильной (как мне кажется) работой с системой контроля версий (git), когда каждый таск из жира - это отдельный branch. И в каждом бранче разрабатывается своя часть функционала. Так вот при переключении между бранчами нужно локальный проект синхронизировать с оргом, а как это сделать нормально если у тебя там остались изменения от предыдущего бранча? Только полностью снести (очистить) орг и задеплоить проект заново.
Плюс CI при каждом коммите берет твой бранч чтобы протестировать, а для этого предварительно тестовый орг полностью очищается, чтобы убрать предыдущую проверку.
Так что очистка орга очень актуальная вещь и ей необходимо оделять особое внимание, потому что если скрипт очистки слетит, то и CI ляжет и ты тоже :) 

Ну если ты заговорил, по поводу правильности, то не таск в отдельный бранч, а User Story или Defect. Потому что User Story или Defect как раз состоят из тасков.

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

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

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

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

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

Чтобы все было так красиво как ты говоришь.
У нас нанимали, какого-то мега крутого, мега дорогого SF архитектора, который настраивал весь dev flow на базе продуктов atlassian. Так вот каждый деплой в твою ветку запускает Bamboo и тот берет именно твою ветку и заливает на тестовый орг и тебе возвращает результат. Т.е. на каждый коммит твоего бранча ты знаешь какие у тебя проблемы и другие знают какие у тебя проблемы :) . А до мержа с веткой релиза еще как до луны. С одно стороны это хорошо - всегда знаешь какие у тебя косяки, с другой твой, wilder, алгоритм как-то правильнее звучит.
Другой еще вопрос - переключения между ветками, обычно на тебя вешают несколько тасков со своими бранчами и нужно делать какую-то работу параллельно - а для этого необходимо переключаться. Это конечно не сложно если есть скрипт, которые очищает орг и заливает новый бранч. Но как в итоге показала практика - это хреново - эти переключения забирают время и если бывает косяк, то забирают много времени. Поэтому (пока еще планирую) настроить себе несколько оргов на такой случай, чтобы каждый бранч подключать к отдельному оргу и прыгать между ними.
Это кстати относится к проблеме ООП (про трату времени). Когда вместо того чтобы вариться в своим коде и пилить свой бранч, я должен еще перепиливать свои методы и классы в других бранчах, чтобы их могли использовать другие разработчики. Короче обычно я параллельно работаю минимум над 3 бранчами - это весело :) 

[quote="Dmitry Shnyrev"]У нас нанимали, какого-то мега крутого, мега дорогого SF архитектора, который настраивал весь dev flow на базе продуктов atlassian. [/quote]
https://developer.atlassian.com/display/SFDC/Setting+Up+Continuous+Integration+and+Deployment

Круто! Надо изучить.
Вообще лучше отсюда начинать https://developer.atlassian.com/display/SFDC/The+Salesforce+Development+Workflow
Добавил в [url=https://salesforce-developer.ru/links]Links[/url]
Вообще ОЧЕНЬ КРУТОЙ материал. Я думаю достоин того чтобы его перевести на русский.

Также чтобы все в кучу - уже выкладывал ссылку на подобную тему 
[url=https://www.youtube.com/watch?v=_eJn2qNDLHQ]Automating Deployment Between Orgs Using Git & Continuous Integration[/url]

[quote="Dmitry Shnyrev"]Круто! Надо изучить.
Вообще лучше отсюда начинать https://developer.atlassian.com/display/SFDC/The+Salesforce+Development+Workflow
Добавил в [url=https://salesforce-developer.ru/links]Links[/url]
Вообще ОЧЕНЬ КРУТОЙ материал. Я думаю достоин того чтобы его перевести на русский.[/quote]
Не крутой ни капельки, там все очень банально и не интересно, и для реальных юзкейсов не совсем приспособлено.

[quote="Dmitry Shnyrev"]Так вот каждый деплой в твою ветку запускает Bamboo и тот берет именно твою ветку и заливает на тестовый орг и тебе возвращает результат. Т.е. на каждый коммит твоего бранча ты знаешь какие у тебя проблемы и другие знают какие у тебя проблемы  . А до мержа с веткой релиза еще как до луны[/quote]

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

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

Очень странное поведение. То есть вы пытаетесь сделать деплой своего бранча, а потом когда делаете мердж у вас могут возникнуть не предвиденные проблемы в виду того что много человек делает свои ветки. Какая-то двойная работа получается. Ну да ладно это ваши правила.[/quote]
Согласен, как-то оч глупо получается, зачем каждый твой коммит заливать на тестой сервер, нужно заливать готовую фичу.

[quote="Dmitry Shnyrev"] 
Это кстати относится к проблеме ООП (про трату времени). Когда вместо того чтобы вариться в своим коде и пилить свой бранч, я должен еще перепиливать свои методы и классы в других бранчах, чтобы их могли использовать другие разработчики. Короче обычно я параллельно работаю минимум над 3 бранчами - это весело :)[/quote]
Знаешь, Дима, чем больше я читаю твои описания вашего рабочего процесса, тем мне чаще кажется, что именно у вас неправильно построенны рабочие процессы и архитектура приложения, в этом не виноваты ни ООП, ни шаблоны, ни VSC, ни CI.
Если что-то занимает очень много времени и мешает нормально разработке, значит оно работает либо не правильно, либо неоптимально и стоит задуматься над улучшениями, чтобы увеличить производительность работы команды.
Без обид, просто хочу помочь.

[quote="wilder"][quote="Gres"][quote="wilder"][quote="Gres"]Синхронизация 2 оргов, как подзадача.[/quote]

Синхронизация или сравнение ?[/quote]
Я не знаю какаю модель разработки и хранения ты будешь использовать.
У меня, например, сравнение делает git, а синхронизацию уже мой билд скрипт.
Всегда нужно исходить из юзкейсов. Для меня, например, актуален бэкап орга и деплой, удаление измененных файлов.
Можем обсудить эти вещи, если интересно.[/quote]

На самом деле очень интересно. Так же не понятно как у тебя гит делает сравнение репо и орга.[/quote]
Дак давай обсудим)
Для каждого орга у меня есть свой репозиторий или ветка в нем, в зависимости от проекта. Скрипт сравнивает изменения и заливает их на сервер.

[quote="Gres"]Дак давай обсудим) 
Для каждого орга у меня есть свой репозиторий или ветка в нем, в зависимости от проекта. Скрипт сравнивает изменения и заливает их на сервер.[/quote]

Ок. У меня все немного по другому.

Есть проект. В проекте несколько оргов, но один репозиторий. Ясное дело что есть много бранчей.

То есть твой скрипт просто заливает дельту на орг ?

[quote="wilder"][quote="Gres"]Дак давай обсудим) 
Для каждого орга у меня есть свой репозиторий или ветка в нем, в зависимости от проекта. Скрипт сравнивает изменения и заливает их на сервер.[/quote]

Ок. У меня все немного по другому.

Есть проект. В проекте несколько оргов, но один репозиторий. Ясное дело что есть много бранчей.

То есть твой скрипт просто заливает дельту на орг ?[/quote]
Да, получает текущую метадату с серверов, находит разницу и заливает.

Самое сложное во всем этом, это формирование package.xml для метадаты, которая имеет подкаталоги.

Никто не пробовал герерировать change set на основе package.xml?

Слышали про новую ФИЧУ:
[quote]
Version Control (Coolest of All)
    Track and Manage Org Changes to improve developer productivity
    Provide a Local Repository to persist Versions
    Track Additions, Mtodifications and Deletions
    Reset Local changes to last Saved Version
    Save Versions to Local Repository
    Compare differences between Versions

[/quote]

[quote="Gres"]Да, получает текущую метадату с серверов, находит разницу и заливает.[/quote]

А почему не с репозитория ?

[quote="Gres"]Самое сложное во всем этом, это формирование package.xml для метадаты, которая имеет подкаталоги.[/quote]

Это как раз не сложно. У меня есть отдельный метод, который это генерит.

[quote="Gres"]Никто не пробовал герерировать change set на основе package.xml?[/quote]

Это что-то новое ? или ты имеешь ввиду просто сформировать zip с дельтой для заливки ?

[quote="wilder"][quote="Gres"]Да, получает текущую метадату с серверов, находит разницу и заливает.[/quote]

А почему не с репозитория ?[/quote]
Просто иногда на одном орге работают несколько разных команд, и приходится следить не только за своими изменениями.

[quote="wilder"][quote="Gres"]Самое сложное во всем этом, это формирование package.xml для метадаты, которая имеет подкаталоги.[/quote]

Это как раз не сложно. У меня есть отдельный метод, который это генерит.[/quote]
На мой взгял, это самое сложно, что пришлось сделать, а все остальное просто элементарно.

[quote="wilder"][quote="Gres"]Никто не пробовал герерировать change set на основе package.xml?[/quote]

Это что-то новое ? или ты имеешь ввиду просто сформировать zip с дельтой для заливки ?[/quote]
Нет, я имею ввиду именно SF Change Set

[quote="Gres"]Нет, я имею ввиду именно SF Change Set[/quote]

Что-то я не нахожу такую возможность. Есть только идея в салесфорсе.

[quote="wilder"][quote="Gres"]Нет, я имею ввиду именно SF Change Set[/quote]

Что-то я не нахожу такую возможность. Есть только идея в салесфорсе.[/quote]
Какая-то тулза умеет это делать, найду ссылку - кину.
Просто хочу узнать, как это реализовано.

Кст, какие юзкейсы вы еще видите или какими пользуютесь, кроме перечисленных выше wilder'ом + синхронизация и бэкап?
Если необходимость в очистке орга?
Просто у меня никогда не возникало такой потребности.

[quote="wilder"]Что-то я не нахожу такую возможность. Есть только идея в салесфорсе.[/quote]
Workbench умеет генерить package.xml по change set.
И обратное тоже вполне возможно, а вот нужно ли это кому-то, я не знаю.