Никто не отрицает тот факт, что непрерывная интеграция необходима.
Кажется, все понимают, что регулярно создавать приложение и запускать тесты очень полезно.
Получить быструю обратную связь, найти проблему, обкатать ее на чистой машине – это все круто.
Это понятно и менеджерам проектов, и разработчикам; даже клиенты рады, когда у них есть возможность попробовать что-то как можно быстрее.
Менеджер, как человек, которому не следует вникать в технические детали, может увидеть готовую сборку Continuous Integration и четко сказать, хорошая она или плохая.
Зеленый – хорошо, красный – плохо.
Очень простой показатель, причем не только для руководителей, но и для всей команды в целом.
Разработчики смотрят на эту ситуацию немного по-другому.
В настоящее время я работаю с командой, в которой мы потихоньку движемся к непрерывной интеграции и пытаемся сократить время получения обратной связи для разработчиков.
Немного о том, почему это очень критично именно для этой команды.
Мы делаем несколько взаимосвязанных продуктов, использующих общие библиотеки.
Работу выполняют разные бригады.
Естественно, бывают случаи, когда одна команда меняет что-то в общей части, что ломает соседнее приложение, поэтому получить отзыв через 1 минуту после чекина гораздо лучше, чем через день от явно недовольного коллеги.
Так вот, не редкость в команде, когда я слышу в адрес QA следующую фразу: «Не берите последний билд, в нем это не работает».
Ответ специалиста по контролю качества: «Хорошо».
И такой диалог я слышал раза 3 за последнюю неделю после чекинов и перед демонстрацией новой версии заказчику.
При этом все сборки в системе CI зеленые.
Оказывается, разработчики придумывают свой индикатор.
Даже если сборка в вашей системе «зеленая», мы лучше знаем, что нам подходит, а что нет. При таком подходе теряется ценность построения процесса непрерывной интеграции в целом, а без него, конечно, можно забыть о непрерывном развертывании в продакшене.
Должно произойти что-то, что изменит порядок вещей в жизни, начните думать по-другому.
Первое, на что следует обратить внимание – это тесты.
Без них непрерывная интеграция невозможна, потому что будут лгать и говорить, что все хорошо.
Мы начнем проверять билды вручную, QA-инженеры будут тестировать один билд за другим, чтобы найти наиболее подходящий для производства, особенно если вдруг прибежит заказчик с горящими глазами и потребует немедленного выпуска новой версии билда.
продукт. Как начать писать тесты, как это делать в проектах с кучей легаси-кода — отдельная тема, но здесь разработчикам нужно быть немного смелее.
Не бойтесь потерпеть неудачу, начните писать тесты.
Плохие тесты лучше, чем отсутствие тестов.
Они хоть как-то проверят систему, и процесс непрерывной интеграции наконец-то начнет приносить пользу.
В первую очередь это приносит пользу команде.
Второй момент, требующий некоторого изменения в сознании, — это отношение к артефактам билда.
Если сборка зеленая, мы должны быть не только уверены, что код в репозитории на такую-то дату работает корректно.
Надо научиться вообще не проверять работу через исходный код. Особенно это актуально для QA-инженеров (или тестировщиков, как их называют в вашей команде).
Надо брать именно то, что дала сборка - финальный пакет с новой версией.
Причина проста, ведь при деплое взять код из специальной ветки или, не дай Бог, на свидании равносильно самоубийству.
Мы обязательно что-то упустим и уже не раз пропускали на практике.
Стоит брать именно то, что нам оставила CI-система, потому что часть работы она уже сделала и повторять ее вручную нет необходимости.
Мне очень нравится цитата моего коллеги: «Ночью компьютеры собираются вместе и смеются над людьми за то, что они выполняют работу, которую могут выполнить компьютеры».
И, конечно, самое главное – это команда.
Кто должен настраивать CI? Кто понимает проблему, если приложение собирается локально, а не в CI-системе.
Да это ты там, инженерный корпус, что-то сломалось.
Не забывайте, что вы — команда.
Команда, отвечающая за продукт и непрерывную интеграцию, — это часть вашей повседневной жизни, часть разработки.
Инженеры-строители, не забывайте, что вы тоже работаете над продуктом, без разработчиков вам никуда.
Получается, что рецептом использования Continuous Integration будут автоматизированные тесты, использование артефактов сборки и команда, которая будет работать как единый механизм для достижения самых высоких целей.
Объединив эти три компонента, мы сделаем большой шаг к конечной цели — непрерывному внедрению в производство и доставке радости нашим пользователям.
Теги: #непрерывная интеграция #разработка через тестирование #tdd #agile
-
Что Такое Хостинг Joomla?
19 Oct, 24 -
Когда Победа - Это Твой Профиль
19 Oct, 24 -
Структуры Против Классов
19 Oct, 24 -
У Скалаксии Есть Проблемы
19 Oct, 24 -
Изобретение Favicon.ico
19 Oct, 24
