Для начала внедрим Continuous Integration в мозг

Тот факт, что Continuous Integration нужен, уже никто не отрицает. Вроде бы всем понятно, что собирать приложение, прогонять тесты на регулярной основе очень полезно. Получить быстрый фидбек, найти проблему, прогнать на чистой машине — это все клево. Это понятно и менеджерам проектов, и девелоперам, даже заказчики радуются, когда есть возможность что-нибудь попробовать поскорее.

Менеджер, как человек, который не должен лезть в технические детали, при виде прошедшего Continuous Integration билда, может однозначно сказать, хороший он или плохой. Зеленый — хороший, красный — плохой. Очень простой индикатор, да и не только для менеджеров, но и для всей команды в целом. Девелоперы на эту ситуацию смотрят немного иначе.

Сейчас я работаю с одной командой, в которой мы потихоньку движемся в сторону непрерывной интеграции и пытаемся сократить время получения фидбека для девелоперов. Немного о том, почему это очень критично именно для этой команды. Мы делаем несколько продуктов, взаимосвязанных, которые используют общие библиотеки. Работа идет разными командами. Естественно, бывают случаи, когда одна команда меняет что-то в общем куске, что ломает соседнее приложение, поэтому получить фидбек через 1 минуту после чекина куда лучше, чем через день от коллеги, который явно недовлен.

Так вот, в команде не редки ситуации, когда я слышу такую фразу, адресованную QA: «Ты последний билд не бери, в нем вот не работает это». Ответ QA: «Хорошо.». И такой диалог я слышал раза 3 за прошедшую неделю после чекинов и перед демонстрацией новой версии заказчику. При этом, все билды в CI-системе, зеленые. Получается, что девелоперы придумывают свой собственный индикатор. Пусть билд и будет зеленым в твоей там системе, но мы-то лучше знаем, что у нас работает, а что нет. При таком подходе ценность вообще построения процесса непрерывной интеграции теряется. А без нее, само собой, можно забыть о непрерывных деплоях на продакшн.

Должно произойти нечто, меняющее порядок вещей в жизни, начать думать как-то иначе. Первое, на что стоит обращать внимание — тесты. Без них непрерывная интеграция невозможна, поскольку она будет врать, говоря, что все хорошо. Мы начнем проверять билды руками, QA инженеры будут тестировать один билд за другим, чтобы найти-таки тот, который максимально подходит для продакшена, особенно если вдруг заказчик прибежит с горящими глазами и требованием немедленного выхода новой версии продукта.

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

Второй момент, который требует некоторого изменения в голове, это отношение к артефактам билда. Если билд зеленый, мы должны быть не просто уверены в том, что код в репозитории на такую-то дату правильно работает. Мы должны научиться вообще не проверять работу через исходный код. Особенно, это касается QA-инженеров (или тестировщиков, как они называются у вас в команде). Они не должны брать код и проверять версию, они должны брать именно то, что выдал билд — финальный пакет с новой версией. Причина проста, мы ведь при деплое не будем брать код и собирать библиотеки. Мы будем брать то, что оставила нам CI-система, ведь она уже сделала часть работы и незачем ее повторять руками. Мне очень нравится фраза, сказанная моим коллегой: «По ночам компьютеры собираются вместе и смеются над людьми, если те делают работу, которую могли бы делать компьютеры».

Ну и, конечно, важным моментом, является команда. Кто должен настраивать CI? Кто разбирается в проблеме, если приложение собирается локально, но на CI системе нет. Да это у вас там, билд инженеров, чего-то сломалось. Не забывайте, что вы — команда. Команда, которая ответственна за продукт, и непрерывная интеграция — это часть вашей повседневной жизни, часть девелопмента. Билд-инженеры, не забывайте, что вы тоже работаете над продуктом, вы без девелоперов никуда.

Получается, что рецептом для применения Continuous Integration будут автоматические тесты, использование артефактов билда и команда, которая будет работать как единый механизм для достижения наивысших целей. Сложив эти три ингредиента вместе, мы сделаем большой шаг к финальной цели — непрерывному деплою на продакшн и доставлению радости нашим пользователям.

Автор: alex4Zero

Источник