Народ, кто чем пользуется для continuous integration? Я имею ввиду кто делает managed package. Пробовали скрипты поверх Migration Tool, но все как то не то. На последнем DreamForce люди из Salesforce Foundation рекламировали вот это (http://developer.salesforcefoundation.org/CumulusCI/), собственно это то чем они собирают Salesforce Non Profit Starter Pack, но уж больно оно сложное и там кастомное middleware надо ставить. Кто чем пользуется, поделитесь?
Jenkins + MT
Похоже они сами не знабт про то что рекламируют. :(
А очень просто. На проекте салесфорса я большую часть времени занимаюсь тем что ручками собираю собираю пакет из коммитов. И на все мои предложения по автоматизации процесса они говорят : "это единственный правильный путь". А архитектор всего этого - индус. Дятел еще тот. Срач на проекте развел невообразимых размеров. И не спешит наводить порядок.
Это от того что сам Salesforce очень большой как удав и голова не знает, чего делает хвост. Архитекторов индусов очень мало толковых, это правда.
Gres подскажи как правильно в Jenkins настройки выставить (хотя бы примерно)
Задача такая - надо подключить Bitbicket(git) репозиторий и при появлении там изменений сливать их и запускать скрипт ant.
С тем как запускать скрипт ant разобрался, а вот с подключением репозитория и push изменений что-то пока не могу толкового примера найти.
Там по ходу плагин для git надо ставить?
Есть контакт. Поставил плагин git для Jenkins и задал путь + ssh key.
Вроде заработало - если запустить task в jenkins, то в указанную папку (wokrspace) сливается код из bitbucket и дальше запускается ant скрипт.
На сколько я помню для этого есть 2 варианта :
WebHook - стучится на юрл и скидывает туда одновление
Email - скидывает обновление на емайл
Это все справедливо для BitBucket. Для гита не в курсе.
Да, про webhook видел - хорошее решение, пока первый кандидат на связку.
Но все-таки не очень хочется чтобы bitbucket "знал" что-то о Jenkins.
Как вариант можно настроить периодический опрос git на изменения - выставить какой-нибудь интервал (скажем 15 мин) и ловить изменения. Да, будет задержка, но если с этим можно согласиться, то вариант нормальный.
Вебхуки достаточно распространены сейчас. Какие причины не дают юзать их?
Вариант с периодическим пулом тоже используются - обычно юзаем когда несколько девелоперов работают сразу в мастер\юат бранчах, и не стоит запускать сборку на каждый коммит. Но это сейчас редкость, все вроде приучены работать в фиче-бранчах.
Причина очевидна. Нет URL на который можно стучаться. Поэтому использую Email notification.
Причина очевидна. Нет URL на который можно стучаться. Поэтому использую Email notification.
Ну, так-то оно может быть, да.
Обычно в более менее больших командах проще провесить дженкинсовский эндпоинт через риверс прокси, но на это нужно заморочиться, нотификация через email выглядит проще.
Привык уже к bamboo, благо даже 70 процентов клиентов юзают весь атлассиановский пакет - нет проблем с доступностью.
Причина очевидна. Нет URL на который можно стучаться. Поэтому использую Email notification.
Ну, так-то оно может быть, да.
Обычно в более менее больших командах проще провесить дженкинсовский эндпоинт через риверс прокси, но на это нужно заморочиться, нотификация через email выглядит проще.
Привык уже к bamboo, благо даже 70 процентов клиентов юзают весь атлассиановский пакет - нет проблем с доступностью.
Ну я в качестве CI использую свой пакет причем на салесфорсе. И только для BitBucket очень не хотелось делать или коммунити или сайт.
Это интересно. Видел несколько CI вендоров построенных строго на форсе, но как-то неоправданно дорого они стоят.
Мне страшно было бы браться за такое на форсе, слишком уж смешные лимиты хип. сайза и вообще всего что связано с парсигом :-/
Не думал перенести на другой стек и захостить на heroku? Развертывание простое, а на рынке определенно не хватает готовых инструментов для танцев с ретрив\деплой чудесами форса.
Если честно думал, но не хочу. CI это только часть системы, а все остальное это чистый CRM.
Если интересно, то есть решение на Форсе и на heroku называется Copado. Но уж больно он там накрутил все не логично. Как мне кажется. Хотя на вкус и цвет....
Если интересно, то есть решение на Форсе и на heroku называется Copado. Но уж больно он там накрутил все не логично. Как мне кажется. Хотя на вкус и цвет....
Copado смотрел, они сейчас действительно на слуху, наряду с Flosum и AutoRabit.
В последнее время часто попадаются гибридные проекты с параллельной разработкой на хероку и под мобильную платформу - тут проще использовать индустриальные CI решения, просто приходится возиться с антом, дабы собирать правильный package.xml и корректировать содержимое мета-файлов на предмет недеплоющихся компонентов.
У меня уже все написано. Жду пока эти уроды реализуют ZIP интерфейс, что бы можно было работать в асинхронных процессах.
Bamboo классный, тоже его используем у себя. Но вот столкнулись с интересной ситуацией и недостаток опыта не позволил решить очень интересную задачу.
Задача - автоматизировать запуск UI тестов Selenium по коммиту в основной бранч.
(возможно вы подскажете как это реализовано у вас)
Тесты написаны на java + selenide и запускаются с помощью ant. Все красиво работает на локальной машине. Поставили задачу сделать запуск на базе Bamboo и elastic instance. И тут возник первый прикол - не очень понятно как эти elastic instance кастомизировать чтобы добавить все необходимое для запуска тестов. Дело еще усугубило то что instance используются на базе Win Server2008, а у меня патологическая неприязнь и незнание серверных технологий на базе win (как собственно и у других из команды).
Взялся использовать знакомые технологии VPS на Ubuntu на Digitalocean.
Все поставил, все настроил (может напишу об это когда-нибудь - очень интересный опыт)
Но тут Bamboo, который Cloud подкинул основную проблему - он работает исключительно с виртаулками от Amazon через elastic agent и поставить remote agent на мой VPS нельзя.
Остался только один способ - запускать команды через SSH, но в этом случае о каком-то анализе (разборе) результатов говорить не приходится - приходит портянка логов и success или fail. Какие там ошибки возвращает нам JUnit можно только догадываться и находить опытным взглядом в тоннах логов.
Поэтому решил немного прокачать скилы и сделать удобной работу с UI тестами - поставил Jenkins и разбираюсь с ним. Удалось настроить чтобы запускались тесты и получать результаты (хотя пока тоже в виде портянки, но это дело времени). Осталось придумать как красиво интегрировать с нашим процессом CI построенным на Bamboo.
Как-то так 
