Ежедневного прогона всех тестов оказалось недостаточно – команды хотели быстрее отлавливать разрушительные изменения. Некоторые команды начали писать скрипты непрерывной сборки, которые непрерывно делали сборку и выполняли юнит– и интеграционные тесты на отдельных машинах. Осознав, что эту систему можно сделать общей для всех команд, Крис Лопес и Джей Корбетт сели и написали «Систему непрерывной сборки Криса и Джея». Теперь любой проект мог развернуть свою систему непрерывной сборки. Достаточно было просто зарегистрировать машину, заполнить файл конфигурации и запустить скрипт.
Система быстро стала популярной, и вскоре большинство проектов в Google перешло на нее. Если тест не проходил, то программа оповещала всех ответственных за изменение по почте. О сбоях стали узнавать через несколько минут после коммита изменений в базу кода. Кроме того, система отмечала «Золотые списки изменений» – контрольные точки в системе контроля версий, в которых успешно проходили все тесты проекта. Теперь разработчики могли ориентироваться на стабильную версию исходников без недавних проблемных изменений. Это очень помогало при выборе стабильной сборки для выпуска.
Но и этого инструмента инженерам оказалось недостаточно. Команды становились больше, проекты – сложнее, потери от поломанных сборок росли. Разработчики строили новые очереди отправок, чтобы защитить системы непрерывной сборки. В ранних реализациях все списки изменений действительно вставали в очередь: система тестировала и одобряла или отклоняла списки последовательно. Если нужно было провести много продолжительных тестов подряд, то между постановкой списка изменений в очередь и его фактической передачей в систему контроля версий могло пройти несколько часов. В следующих версиях уже реализовали параллельное выполнение ожидающих списков изменений, но они запускались изолированно друг от друга. Хотя это могло создавать проблемы нарушения последовательности потоков, такие случаи были редки, их оперативно обнаруживала система непрерывной сборки. Возможность заливки кода через несколько минут после отправки запроса экономила много времени. Это компенсировало затраты на исправление редких падений системы непрерывной сборки.
Так большинство крупных проектов Google перешло на использование очередей на отправку. Во многих командах даже выделяли специального человека на роль «смотрителя сборки», задача которого заключалась в том, чтобы быстро реагировать на любые проблемы, выявленные очередью проверки или системой непрерывной сборки.