Pull to refresh

Comments 11

Почему вы не использовали для решения задачи какую-либо из существующих систем CI, например, Jenkins, Team City, Bamboo?
Не совсем понял вопрос. Как пересекаются CI и то, что описал я? На сколько я знаю — CI генерирует список изменений по факту обновления кода в репозитории\ветке, а не по факту выкладывания кода на сервер.
Под выкладыванием кода на сервер вы понимаете процесс: забрать код из СКВ > сконфигурить/собрать/скомпилировать (выбрать ваш вариант) > задеплоить результат на сервер, откуда команда тестирования или кто-то еще сможет посмотреть на результат? При этом после успешного деплоя необходимо сгенерировать письмо, которое будет отправлено всем заинтересованным лицам с информации о том, что: очередной процесс обновления прошел успешно, в новую версию попали такие-то изменения, дальше идут подробности об изменениях. Если я правильно понял суть вашей задачи, то все это умеют делать системы, о которых я написал выше, если неправильно — поправьте меня.
Да, вы всё верно поняли.
Но у нас несколько бранчей (CI настроен только на 1 из них — testing). При этом от одного бранча могут обновляться несколько серверов, в частности сервера stable и production идут из ветки master, причём stable может обгонять production на несколько коммитов, т.к. на нём тестируются хотфиксы.
Я не представляю, как от Jenkins`а получить требуемое.
Про Jenkins не скажу, но у нас Bamboo с задачей автоматически раскидать код из одного бранча на несколько стендов справляется. Думаю, что Jenkins тоже можно настроить, было бы желание. Другой вопрос, нужно ли вам это. Нам, самописное решение не подошло бы — слишком много стендов (более 10) и веток примерно столько же — замучались бы поддерживать, поэтому без централизованного сервера сборки никак. Вопрос просто в том, нужно ли изобретать велосипед в вашем случае.
У нас php — сборки как таковой нет. Так что весь процесс деплоя занимает не более минуты.
То, что у вас php не меняет сути дела. Мое мнение такое — зачем придумывать велосипед, если его уже придумали, лучше потратить время на что-нибудь более полезное. Если в вашем случае время разработки вашего метода
Мы сначала прикрутили capistrano для деплоя, а потом уже начали внедрять Jenkins. Поэтому отправка таких уведомлений из capistrano+git показалась вполне логичной.

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

Спасибо.
На сколько я знаю — CI генерирует список изменений по факту обновления кода в репозитории\ветке, а не по факту выкладывания кода на сервер.

В корне не согласен! CI выполняет этапы сборки. Какие этапы вы определите, такие он и будет выполнять, а поскольку функционалльность CIS (во всяком случае Jenkins) может быть расширена не только плагинами, но и путем выполнениния пользовательских скриптов — этапы сборки могут быть определены самые разнообразные.

Резюме: безусловно создавать кастомные решения нужно, но удобнее было бы их наращивать на уже готовом CIS.
у нас самописная утилита заполняет гугл календарь и гугль таблицу. Так все в команде могут увидеть в календаре — деплои веток проекта, а в таблице — на какие сервера какие фичи деплоились (для QAs удобно знать можно ли тестировать).
Sign up to leave a comment.

Articles