Отдел новостей 11 ноября 2013, 12:03

Continuous Integration на практике. Часть 1

Недавно cостоялась 4-ая встреча PHP User Group Minsk в коворкинге ME100. Такие встречи проходят раз в месяц, а их организаторами являются минские PHP-разработчики. Цель таких встреч — поделиться опытом и знаниями, посмотреть, как похожие процессы построены в других командах/компаниях. Это скорее неформальные мероприятия, которые проходят в режиме свободной дискуссии и в которых принимают участие PHP-разработчики из разных IT-компаний в Минске.

Основными темами на 4-ой встрече PHP User Group Minsk, которая прошла в октябре, были Symfony, Continuous Integration, NodeJS и DDD. На этой встрече выступил и наш Tech Lead Антон Сердюк с докладом на тему Continuous Integration. На этой встрече выступил и наш Tech Lead Антон Сердюк с докладом на тему Continuous Integration.

В своем докладе Антон подробно рассказал о том, как код 15-ти разработчиков Startup Labs два раза в неделю выкатывается на продакшен: «Мы разрабатываем B2B систему, не очень большую, но и не очень маленькую. Проект длится уже полтора года, и в разное время над ним работали от 4 до 15 разработчиков (сейчас 15). Трафик у нас небольшой, но дорогой, данных тоже не очень много — 15 гигабайт. Незапланированный downtime нам обходится дорого (однако есть maintenance window), т.е. мы можем позволить себе небольшой запланированный downtime. Баги на продакшене нам тоже обходятся дорого, потому что у нас не соцсеть: люди делают бизнес c помощью нашей системы и просто уйдут к конкурентам, если увидят, что у нас все нестабильно.

Технологии, которые мы используем:

PHP 5.4;
Java 7;
PostgreSQL для БД;
RabbitMQ как шина сообщений, соединяющая все компоненты между собой.

Примерный список фреймворков:

в Java части — Hibernate и JUnit;
в PHP части — Symfony 2, Silex для каких-то мелких компонентов, Behat для функциональных тестов, PHPUnit для юнит-тестов.

Мы любим Agile и основные принципы берем из него:

делаем маленькие изменения;
часто поставляем их клиенту;
рано принимаем фидбек.

На пути становления наших процессов были определенные вещи, от которых мы по тем или иным причинам осознанно отказались.

1. В первую очередь это фиче-бранчи. Вообще, как мне кажется, фиче-бранчи очень слабо вяжутся с идеей Continuous Integration. Я бы даже сказал: либо фиче-бранчи, либо CI. Проблема в том, что код в фиче-бранче не интегрируется с остальным кодом, поэтому может сильно расходиться с кодом внутри других фиче-бранчей, даже если регулярно к нему подмерживается мастер.

Второй аргумент против фиче-бранчей — это то, что не всегда можно понять, что же происходило уже иногда даже на следующий день. Ниже на скриншотe — история гита проекта другой команды, состоящей примерно из 15 девелоперов и верстальщиков. Разобраться в каком-то нетривиальном кейсе в такой истории получается очень сложно.

2. Далее мы отказались от релиз-бранчей. Они нужны, если надо поддерживать несколько версий ПО. Обычно при разработке продукта это не нужно, но многие, наверное, смотрят на популярные библиотеки и делают так, как они.

3. Также мы отказались от всяких develop-бранчей. Часто при создании проекта даже на двух девелоперов создают сразу staging и master. Разработку ведут в develop, а потом мержат это все в другие бранчи. Для нас это оказалось избыточно, и мы не нашли в этом никакой пользы.

4. Мы не делаем релиз-теги. Хотя это не мешает работе и не требует сложной поддержки, пока что необходимости в них у нас тоже не было.

5. В отдельности можно сказать, что мы не используем git-flow. Я вообще не понимаю, почему так много людей его боготворят. Это огромный оверкилл, заставляющий даже плагины к гиту использовать, потому что без них работать уже неудобно.

Что мы используем, так это Continuous Integration. Что это значит для нас:

девелопер должен каждый день интегрироваться с основной (и единственной) веткой разработки;
каждый коммит собирается на билд-сервере;
на каждый билд выполняются все автотесты;
красные билды надо фиксить быстро.

Это все в идеале. Иногда случаются ситуации, когда девелоперы не интегрируются по три дня. Иногда бывает, что билд целый день красный. Но мы стремимся к этим принципам.

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

Важный момент с Continuous Integration — это то, что ты постоянно должен интегрировать свой код с мастером. Понятное дело, что не все фичи делаются меньше дня. Для таких случаев есть интересный подход: Branch By Abstraction. Первым делом девелопер коммитит выключатель для фичи, который выключен по умолчанию. Далее он может постоянно интегрироваться с мастером, не боясь что-то сломать. Его код может уже быть (а иногда не раз) задеплоен в выключенном состоянии на продакшен. Потом, когда фича подходит к концу, она включается и отправляется в QA, которые ее проверяют, и если все хорошо, то уже следующий релиз ее включит на продакшене.

Нет смысла говорить о CI без автотестов. Автотесты мы очень любим и активно используем. QA у нас пишут Behat сценарии до разработки фичи или во время ее разработки, а девелоперы их имплементят. Мы стараемся абсолютно каждую фичу покрывать сценариями. Таким образом, получается отличный большой пак регрессионных тестов, который позволяет нам достаточно просто и безболезненно проводить рефакторинг.

Вот несколько цифр с проекта:

У нас уже 1000 Behat сценариев (это не включая юнит-тесты, которых у нас поменьше). Билд длится в среднем 15 минут (включая прогон всех функциональных тестов). У нас два достаточно мощных билд-сервера и примерно 15 билдов в день. Нам важно, чтобы время билда было минимальным, тесты занимают бóльшую часть времени билда, поэтому мы постоянно работаем над их ускорением.

Два раза в неделю мы деплоимся на продакшен. Деплой запускается вручную. У нас для этого собирается мини-команда из девелопера, менеджера и архитектора, которая нажимает на кнопку и проверяет потом, все ли в порядке. Дополнительно у нас есть сервер nb-prod — он инкрементально обновляется вместе с продакшеном, это песочница для других команд, которым нужно интегрироваться с нашим продуктом.

На данный момент в нашем процессе деплоя на продакшен нету стратегии поведения во время возникновения каких-то проблем. Мы не можем принципиально откатиться назад. На самом деле это не так уж страшно, потому что кейсы, когда что-то идет не так, крайне редки: очень большая часть проблем с деплоем отсекается на этапе теста миграций на базе продакшена».

Более подробно о том, как происходит сам процесс билда и какие фазы он в себя включает, можно будет узнать в нашем следующем посте.

Посмотреть полную презентацию можно здесь.