Менеджер, как человек, который не должен лезть в технические детали, при виде прошедшего Continuous Integration билда, может однозначно сказать, хороший он или плохой. Зеленый — хороший, красный — плохой. Очень простой индикатор, да и не только для менеджеров, но и для всей команды в целом. Девелоперы на эту ситуацию смотрят немного иначе.
Сейчас я работаю с одной командой, в которой мы потихоньку движемся в сторону непрерывной интеграции и пытаемся сократить время получения фидбека для девелоперов. Немного о том, почему это очень критично именно для этой команды. Мы делаем несколько продуктов, взаимосвязанных, которые используют общие библиотеки. Работа идет разными командами. Естественно, бывают случаи, когда одна команда меняет что-то в общем куске, что ломает соседнее приложение, поэтому получить фидбек через 1 минуту после чекина куда лучше, чем через день от коллеги, который явно недовлен.
Так вот, в команде не редки ситуации, когда я слышу такую фразу, адресованную QA: «Ты последний билд не бери, в нем вот не работает это». Ответ QA: «Хорошо.». И такой диалог я слышал раза 3 за прошедшую неделю после чекинов и перед демонстрацией новой версии заказчику. При этом, все билды в CI-системе, зеленые. Получается, что девелоперы придумывают свой собственный индикатор. Пусть билд и будет зеленым в твоей там системе, но мы-то лучше знаем, что у нас работает, а что нет. При таком подходе ценность вообще построения процесса непрерывной интеграции теряется. А без нее, само собой, можно забыть о непрерывных деплоях на продакшн.
Должно произойти нечто, меняющее порядок вещей в жизни, начать думать как-то иначе. Первое, на что стоит обращать внимание — тесты. Без них непрерывная интеграция невозможна, поскольку она будет врать, говоря, что все хорошо. Мы начнем проверять билды руками, QA инженеры будут тестировать один билд за другим, чтобы найти-таки тот, который максимально подходит для продакшена, особенно если вдруг заказчик прибежит с горящими глазами и требованием немедленного выхода новой версии продукта.
Как начать писать тесты, как это сделать в проектах к кучей легаси-кода — это отдельная тема, но тут девелоперам надо быть чуть храбрее. Не бойтесь провалиться, начните писать тесты. Плохие тесты лучше, чем никакие. Они хоть как-то будут проверять систему, а процесс непрерывной интеграции наконец-то начнет приносить пользу. Прежде всего, пользу именно команде.
Второй момент, который требует некоторого изменения в голове, это отношение к артефактам билда. Если билд зеленый, мы должны быть не просто уверены в том, что код в репозитории на такую-то дату правильно работает. Мы должны научиться вообще не проверять работу через исходный код. Особенно, это касается QA-инженеров (или тестировщиков, как они называются у вас в команде). Они не должны брать код и проверять версию, они должны брать именно то, что выдал билд — финальный пакет с новой версией. Причина проста, мы ведь при деплое не будем брать код и собирать библиотеки. Мы будем брать то, что оставила нам CI-система, ведь она уже сделала часть работы и незачем ее повторять руками. Мне очень нравится фраза, сказанная моим коллегой: «По ночам компьютеры собираются вместе и смеются над людьми, если те делают работу, которую могли бы делать компьютеры».
Ну и, конечно, важным моментом, является команда. Кто должен настраивать CI? Кто разбирается в проблеме, если приложение собирается локально, но на CI системе нет. Да это у вас там, билд инженеров, чего-то сломалось. Не забывайте, что вы — команда. Команда, которая ответственна за продукт, и непрерывная интеграция — это часть вашей повседневной жизни, часть девелопмента. Билд-инженеры, не забывайте, что вы тоже работаете над продуктом, вы без девелоперов никуда.
Получается, что рецептом для применения Continuous Integration будут автоматические тесты, использование артефактов билда и команда, которая будет работать как единый механизм для достижения наивысших целей. Сложив эти три ингредиента вместе, мы сделаем большой шаг к финальной цели — непрерывному деплою на продакшн и доставлению радости нашим пользователям.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html
Комментариев нет:
Отправить комментарий