Джин Ким - Руководство по DevOps

Блэнд описывал, что одним из последствий такого большого числа талантливых разработчиков в компании Google стало появление у них «синдрома самозванца». Этот термин был введен психологами, чтобы неформально описать людей, которые не в состоянии глубоко осознать свои же достижения. В Википедии этот термин описывается так: «Несмотря на внешние доказательства состоятельности, подверженные этому синдрому продолжают считать, что они обманщики и не заслуживают успеха, которого достигли. Успехи они, как правило, объясняют удачей, попаданием в нужное место и время или введением других в заблуждение, будто они умнее и компетентнее, чем есть на самом деле». Прим. авт.

Они создали обучающие программы, распространявшиеся через известный информационный бюллетень Testing on the Toilet (который они развешивали в санитарных комнатах), план работы и сертификационную программу Test Certified и провели несколько собраний fix-it («исправь это»), которые помогли командам улучшить автоматическое тестирование процессов, с тем чтобы они смогли воспроизвести потрясающие результаты, которых сумела добиться команда GWS. Прим. авт.

В разработке термин «непрерывная интеграция» часто означает непрерывную интеграцию нескольких ветвей кода в общую ветку и проверку того, что интегрированный код успешно проходит модульное тестирование. Однако в контексте непрерывной доставки и DevOps непрерывная интеграция также означает работу в среде, близкой к производственной, и успешное прохождение приемочных и интеграционных тестов. Джез Хамбл и Дэвид Фарли устранили эту неоднозначность, обозначив последнее понятие как CI+. Далее в этой книге термин «непрерывная интеграция» будет всегда использоваться в контексте методов CI+. Прим. авт.

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

Мы можем даже потребовать, чтобы эти инструменты запускались до внесения изменений в систему контроля версий (например, выполнялся предфиксационный перехват). Мы также можем запускать эти инструменты у разработчика в интегрированной среде разработки (IDE), в которой разработчик редактирует, компилирует и запускает код, что делает обратную связь еще более быстрой. Прим. авт.

Мы также можем использовать в качестве механизма упаковки контейнеры, такие как Docker. Контейнеры обеспечивают возможность «написано однажды, используется везде». Эти контейнеры создаются как часть нашего процесса сборки и могут быть быстро развернуты и запущены в любой среде. Поскольку один и тот же контейнер будет работать в любой среде, мы можем обеспечить согласованность всех наших артефактов сборки. Прим. авт.

Именно эта проблема привела к созданию метода непрерывной интеграции. Прим. авт.

Существует большая категория архитектурных методов и способов тестирования, используемых, чтобы справиться с проблемами тестирования в случаях, требующих входных данных от внешних точек интеграции, включая «заглушки», «мок-объекты», «виртуализацию служб» и так далее. Это становится еще более важным для приемочного и интеграционного тестирования, в которых необходимо гораздо сильнее полагаться на состояние внешних данных. Прим. авт.

Мы должны делать это только тогда, когда наши команды уже оценили автоматизированное тестирование — этим показателем разработчики и менеджеры могут легко манипулировать. Прим. авт.

Издано на русском языке: М.: Вильямс, 2011. На обложке русскоязычного издания в качестве авторов указаны Джез Хамбл и Дэвид Фарли. Прим. перев.

Начи Нагаппан, Майкл Максимилиан и Лори Уильямс (из компаний Microsoft Research, IBM Almaden Labs и университета Северной Каролины соответственно) провели исследование, которое показало, что команды, использовавшие TDD, выпускали код на 60–90 % качественнее по показателю плотности дефектов по сравнению с командами, не использовавшими TDD, и тратили на это всего на 15–35 % больше времени. Прим. авт.