Как непрерывная доставка может работать на практике?

22

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

(Изменить: чтобы было ясно, у меня всегда много тестов, запускаемых автоматически. Мой вопрос о том, как получить уверенность при каждой регистрации, и я понимаю, что это полная форма CD. Альтернатива - не годичные циклы. Это итерации каждую неделю (которые некоторые могут считать CD, если все сделано правильно), две недели или месяц; включая старомодный контроль качества в конце каждой, дополняющий автоматизированные тесты.)

  • Полное тестовое покрытие невозможно. Вы должны потратить много времени - а время - деньги - на каждую мелочь. Это ценно, но можно потратить время на улучшение качества другими способами.
  • Некоторые вещи сложно проверить автоматически. Например, GUI. Даже Selenium не скажет вам, является ли ваш GUI ненадежным. Доступ к базе данных трудно проверить без громоздких приспособлений, и даже это не охватит странные случаи в вашем хранилище данных. Так же безопасность и многое другое. Только код бизнес-уровня эффективно тестируется модулем.
  • Даже на бизнес-уровне большинство кода не являются простыми функциями, чьи аргументы и возвращаемые значения могут быть легко изолированы для целей тестирования. Вы можете потратить много времени на создание фиктивных объектов, которые могут не соответствовать реальной реализации.
  • Интеграционные / функциональные тесты дополняют модульные тесты, но для их выполнения требуется много времени, поскольку они обычно включают повторную инициализацию всей системы в каждом тесте. (Если вы не выполните повторную инициализацию, среда тестирования будет несовместимой.)
  • Рефакторинг или любые другие изменения нарушают множество тестов. Вы тратите много времени на их исправление. Если это вопрос проверки значимых изменений спецификаций, это нормально, но часто тесты ломаются из-за бессмысленных низкоуровневых деталей реализации, а не из-за того, что действительно предоставляет важную информацию. Зачастую настройка фокусируется на переработке внутренних компонентов теста, а не на проверке проверяемой функциональности.
  • Полевые отчеты об ошибках не могут быть легко сопоставлены с точной микроверсией кода.
Джошуа Фокс
источник
Это работает очень хорошо для Etsy slideshare.net/OReillyOSCON/… !
YoTsumi
4
Непрерывная доставка не требует тестирования (но это помогает). Это относится к тому факту, что вещи, которые вы строите на регулярной основе, МОГУТ быть отправлены заказчику в случае необходимости.
Интересно, что ваши возражения против непрерывной доставки в основном сфокусированы на тестировании как элементе CD. Тем не менее, это только одна часть головоломки: вам нужны компетентные внутренние инструменты, разработчики посвятили себя строгим проверкам качества, широчайшему подходу приоритизации в ваших автоматизированных тестах, не говоря уже о сильной организационной поддержке. Это можно сделать, но требуется много людей, чтобы посвятить себя делу.
Стивен Гросс
1
@ Стефан Да, я сосредоточен на тестировании, потому что я согласен по всем другим аспектам. Я тоже за тестирование. Я просто не понимаю, как вы можете иметь достаточно уверенности, чтобы развернуть каждую регистрацию.
Джошуа Фокс
@ Торбьерн Равн Андерсен. Конечно, CD, кажется, требует тестирования. Как вы можете быть уверены в том, что автоматически отправляете каждую регистрацию без нее?
Джошуа Фокс

Ответы:

29

мой многолетний опыт разработки программного обеспечения свидетельствует о том, что на практике это не может работать.

Ты пробовал это? Мы с Дейвом написали книгу, основанную на многолетнем опыте коллектива, как самих себя, так и других высокопоставленных людей в ThoughtWorks, которые фактически занимаются тем, что обсуждают. Ничто в книге не является умозрительным. Все, что мы обсуждаем, было опробовано и протестировано даже на больших, распределенных проектах. Но мы не предлагаем вам принять это на веру. Конечно, вы должны попробовать это сами, и, пожалуйста, напишите, что вы находите работ, а что нет, включая соответствующий контекст, чтобы другие могли учиться на вашем опыте.

Непрерывная доставка уделяет большое внимание автоматизированному тестированию. Мы тратим около 1/3 книги, говоря об этом. Мы делаем это потому, что альтернатива - ручное тестирование - является дорогой и подвержена ошибкам, и на самом деле не является отличным способом создания высококачественного программного обеспечения (как сказал Деминг: «Прекратить зависимость от массового контроля для достижения качества. Улучшить процесс и улучшить качество сборки в продукт на первом месте ")

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

Конечно, полное тестовое покрытие невозможно, но какова альтернатива: нулевое тестовое покрытие? Здесь есть компромисс. Где-то посередине - правильный ответ для вашего проекта. Мы считаем, что в целом вы должны ожидать, что вы потратите около 50% своего времени на создание или поддержку автоматических тестов. Это может показаться дорогостоящим, если не учитывать стоимость комплексного ручного тестирования и исправления ошибок, которые появляются у пользователей.

Некоторые вещи сложно проверить автоматически. Например, GUI. Даже Selenium не скажет вам, является ли ваш GUI ненадежным.

Конечно. Проверьте тестовый квадрант Брайана Марика. Вам все еще нужно выполнить пробное тестирование и юзабилити-тестирование вручную. Но это то, для чего вы должны использовать своих дорогих и ценных людей, а не регрессионное тестирование. Ключевым моментом является то, что вам нужно создать конвейер развертывания, чтобы вам удавалось выполнять дорогостоящие ручные проверки только для сборок, которые прошли полный набор автоматических тестов. Таким образом, вы уменьшаете сумму денег, которую вы тратите на ручное тестирование, и количество ошибок, которые когда-либо вносятся в ручное тестирование или производство (к тому времени их исправление очень дорого). Правильное автоматическое тестирование намного дешевле в течение жизненного цикла продукта, но, конечно, это капитальные затраты, которые амортизируются со временем.

Доступ к базе данных трудно проверить без громоздких приспособлений, и даже это не охватит странные случаи в вашем хранилище данных. Так же безопасность и многое другое. Только код бизнес-уровня эффективно тестируется модулем.

Доступ к базе данных проверяется неявно вашими функциональными приемочными тестами на сквозной основе. Для обеспечения безопасности потребуется сочетание автоматического и ручного тестирования - автоматического тестирования на проникновение и статического анализа для обнаружения (например) переполнения буфера.

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

Конечно, автоматизированные тесты стоят дорого, если вы плохо строите свое программное обеспечение и свои тесты. Я настоятельно рекомендую ознакомиться с книгой «Растущее объектно-ориентированное программное обеспечение, руководствуясь тестами», чтобы понять, как сделать это правильно, чтобы ваши тесты и код работали со временем.

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

Один из продуктов, над которым я работал, имеет набор из 3500 сквозных приемочных тестов, который длится 18 часов. Мы запускаем его параллельно на сетке из 70 ящиков и получаем обратную связь через 45 метров. На самом деле все еще дольше, чем идеально, поэтому мы запускаем его как второй этап конвейера после того, как модульные тесты пройдут через несколько минут, поэтому мы не тратим наши ресурсы на сборку, для которой у нас нет базового уровня уверенность в.

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

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

Полевые отчеты об ошибках не могут быть легко сопоставлены с точной микроверсией кода.

Если вы тестируете и отпускание чаще (часть точки CD) , то это относительно просто определить изменение , которое вызвало ошибку. Весь смысл CD состоит в том, чтобы оптимизировать цикл обратной связи, чтобы вы могли идентифицировать ошибки как можно скорее после того, как они возвращены в систему контроля версий - и, действительно, предпочтительно до того, как они будут зарегистрированы (именно поэтому мы запускаем сборку и модульные тесты до заезда).

Джез Хамбл
источник
Спасибо за Ваш ответ. Да, я верю в тестирование. Мои проекты получили хорошее покрытие кода от автоматических тестов, выполняемых с ежедневной сборкой. Я просто говорю, что вам нужна какая-то итерация перед выпуском. «Вам все еще нужно выполнить предварительное тестирование ... вручную». Я не понимаю Полная система CD развертывается при каждой регистрации. Как вы можете это сделать, если включите ручное тестирование?
Джошуа Фокс
3
Мне нравится различать непрерывную доставку и непрерывное развертывание. Вот в чем разница. Непрерывная поставка означает, что вы постоянно поддерживаете готовность системы к работе и можете запускать ее по требованию одним нажатием кнопки. Релиз - это деловое решение. Непрерывное развертывание является ограничивающим случаем, когда вы выпускаете каждую хорошую сборку (обратите внимание, что не каждая регистрация - некоторые проверки не приводят к выпускной сборке). В обоих случаях вы можете включить ручные проверки: ключом является концепция конвейера развертывания .
Джез Хамбл
Относительно «Доступ к базе данных неявно проверяется вашими функциональными приемочными тестами на основе сквозного сценария». Ключевая проблема заключается в том, что это неявно . Люди, кажется, довольны этим, но это очень трата времени; вместо того, чтобы говорить о проблеме «Это то, что я ожидал от БД и получил это вместо этого», он говорит: «Что-то сломалось в одном из 100 слоев».
atoth
11

Во-первых, компакт-диск требует одной большой психологической корректировки - вы должны признать, что иногда все будет сломано, что бы вы ни делали. В конце концов, вы не можете доказать отрицательный.

Пройдя через это, вы понимаете, что вам нужны инструменты и процедуры для: а) очень быстрого выявления этих ошибок и б) либо отката, либо развертывания обновления очень эффективно. Более того, если вы действительно пьете коктейль на компакт-диске, вы действительно вносите множество небольших, точечных изменений, которые легко откатить и которые не могут привести к серьезным ошибкам в приложении. Даже парни, которые действительно практикуют CD, обрабатывают крупные изменения более традиционным способом.

Уайетт Барнетт
источник
"небольшие ... изменения ... не должны быть в состоянии ввести ошибки всего приложения". Даже в хорошо продуманном коде это может произойти. Например, вы добавляете div, который выталкивает другой div из поля зрения в одном конкретном браузере. Например, нулевое значение появляется в неожиданном угловом случае, вызывая исключение и вообще не давая визуализации графического интерфейса. Да, вы должны протестировать все возможное, как и я, но неизбежно случаются ошибки, и маленькие ошибки могут нарушить работу всего приложения.
Джошуа Фокс
Но их по-прежнему легко найти и исправить, что является главной целью.
Уайетт Барнетт
2

У каждой системы есть риски, и у каждого риска есть потенциальные затраты. Если стоимость какого-то крохотного риска, такого, который может потребоваться месяцами или годами для тщательного тестирования и контроля качества, достаточно высока (программное обеспечение в вашем кардиостимуляторе), вы не отправите его без длительного периода тестирования. замороженный выпуск. Если цена неудачи достаточно мала, возможно, вы отправляете ее постоянно с нулевым тестированием (страница вашей кошки в Facebook).

hotpaw2
источник
Да. Для большинства производственных приложений риск находится где-то посередине. И мне кажется, что риск таков, что мы не хотим развертывать при каждой регистрации, даже при автоматическом тестировании. Кажется, раунд QA всегда нужен. Но примерно еженедельные выпуски кажутся мне выполнимыми.
Джошуа Фокс
1

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

Вам не нужно 100% покрытие, вам нужно достаточно, чтобы быть уверенным в своей системе, чтобы изменения в одном месте не сломали вещи, которые вы уже доказали своей работой.

Некоторые вещи сложно проверить автоматически. Например, GUI. Даже Selenium не
скажет вам, является ли ваш GUI ненадежным. Доступ к базе данных трудно проверить без громоздких приспособлений, и даже это не охватит странные случаи в вашем хранилище данных.

Однако доступ к базе данных тривиален. Вам не нужно много тестов на вашем слое данных, поскольку он просто получает и устанавливает данные. Самое главное, чтобы в случае сбоя он откатывался и регистрировал проблему, чтобы вы могли ее исправить.

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

Тогда многие из ваших функций / классов слишком велики. Они должны быть написаны для проверки.

Вы можете потратить много времени на создание фиктивных объектов, которые могут не соответствовать реальной реализации.

Однако ввод-вывод фиктивного объекта должен соответствовать ожидаемому. Что происходит внутри, неважно.

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

Они не должны выполняться все время. Так же, как необходимо.

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

Тогда ваш код слишком тесно связан, а ваши тесты плохо написаны.

Полевые отчеты об ошибках не могут быть легко сопоставлены с точной микроверсией кода.

Не уверен, что ты здесь делаешь? Если есть ошибка, напишите тест, чтобы показать ее существование, а затем исправьте.

CaffGeek
источник
«Ввод-вывод фиктивного объекта должен соответствовать ожидаемому». «Создание МО, полностью реализующее спецификацию интерфейса, отнимает много времени. Хуже того, их нужно постоянно обновлять, чтобы эффективно писать весь код дважды (один раз для производства и один раз для МО).
Джошуа Фокс
1

У нас отлично работает, но наши клиенты в основном внутренние. Многократные сборки выполняются в течение дня, сломанные сборки не допускаются, используется механизм веб-запуска, поэтому пользователи получают последнюю версию при каждом запуске. Одна вещь состоит в том, что компакт-диск устраняет множество проблем. Да, у вас постоянно есть проблемы с совместимостью, однако, поскольку вы каждый раз внедряете только небольшие изменения, с ними действительно легко справиться. Уровень стресса на CD НАМНОГО ниже, чем когда мы делали большие обновления, и мы должны были надеяться, что все было правильно, так как в случае поломки было бы так много кода, который нужно просмотреть.

Брайан Кноблаух
источник
-4

Честно говоря, ВСЕ программное обеспечение находится в постоянной поставке! Самое главное - вытащить это за дверь! Заставьте своих пользователей использовать его и расставьте приоритеты запросов функций и устранения ошибок после этого.

«Корабли настоящих художников»
- Стив Джобс.

Гари Уиллоуби
источник
альтернатива CD не годичные циклы. Это итерации каждую неделю, две недели или месяц.
Джошуа Фокс