zvirusz19 авг 2011 в 08:02

Отправка уведомлений на почту при деплое проекта

4 мин

6.1K

Комментарии 11

91koff 19 авг 2011 в 08:45

Почему вы не использовали для решения задачи какую-либо из существующих систем CI, например, Jenkins, Team City, Bamboo?

zvirusz 19 авг 2011 в 08:51

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

91koff 19 авг 2011 в 08:58

Под выкладыванием кода на сервер вы понимаете процесс: забрать код из СКВ > сконфигурить/собрать/скомпилировать (выбрать ваш вариант) > задеплоить результат на сервер, откуда команда тестирования или кто-то еще сможет посмотреть на результат? При этом после успешного деплоя необходимо сгенерировать письмо, которое будет отправлено всем заинтересованным лицам с информации о том, что: очередной процесс обновления прошел успешно, в новую версию попали такие-то изменения, дальше идут подробности об изменениях. Если я правильно понял суть вашей задачи, то все это умеют делать системы, о которых я написал выше, если неправильно — поправьте меня.

zvirusz 19 авг 2011 в 09:12

Да, вы всё верно поняли.
Но у нас несколько бранчей (CI настроен только на 1 из них — testing). При этом от одного бранча могут обновляться несколько серверов, в частности сервера stable и production идут из ветки master, причём stable может обгонять production на несколько коммитов, т.к. на нём тестируются хотфиксы.
Я не представляю, как от Jenkins`а получить требуемое.

91koff 19 авг 2011 в 11:13

Про Jenkins не скажу, но у нас Bamboo с задачей автоматически раскидать код из одного бранча на несколько стендов справляется. Думаю, что Jenkins тоже можно настроить, было бы желание. Другой вопрос, нужно ли вам это. Нам, самописное решение не подошло бы — слишком много стендов (более 10) и веток примерно столько же — замучались бы поддерживать, поэтому без централизованного сервера сборки никак. Вопрос просто в том, нужно ли изобретать велосипед в вашем случае.

zvirusz 19 авг 2011 в 13:44

У нас php — сборки как таковой нет. Так что весь процесс деплоя занимает не более минуты.

91koff 19 авг 2011 в 17:05

То, что у вас php не меняет сути дела. Мое мнение такое — зачем придумывать велосипед, если его уже придумали, лучше потратить время на что-нибудь более полезное. Если в вашем случае время разработки вашего метода

zvirusz 20 авг 2011 в 00:56

Мы сначала прикрутили capistrano для деплоя, а потом уже начали внедрять Jenkins. Поэтому отправка таких уведомлений из capistrano+git показалась вполне логичной.

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

Спасибо.

Gluttton 19 авг 2011 в 20:16

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

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

Резюме: безусловно создавать кастомные решения нужно, но удобнее было бы их наращивать на уже готовом CIS.

le0pard 19 авг 2011 в 10:48

у нас самописная утилита заполняет гугл календарь и гугль таблицу. Так все в команде могут увидеть в календаре — деплои веток проекта, а в таблице — на какие сервера какие фичи деплоились (для QAs удобно знать можно ли тестировать).

Gluttton 19 авг 2011 в 20:25

Возможно вот это с учетом вот этого и этого подойдет?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий