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

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

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

• Полное тестовое покрытие невозможно. Вы должны потратить много времени - а время - деньги - на каждую мелочь. Это ценно, но можно потратить время на улучшение качества другими способами.
• Некоторые вещи сложно проверить автоматически. Например, GUI. Даже Selenium не скажет вам, является ли ваш GUI ненадежным. Доступ к базе данных трудно проверить без громоздких приспособлений, и даже это не охватит странные случаи в вашем хранилище данных. Так же безопасность и многое другое. Только код бизнес-уровня эффективно тестируется модулем.
• Даже на бизнес-уровне большинство кода не являются простыми функциями, чьи аргументы и возвращаемые значения могут быть легко изолированы для целей тестирования. Вы можете потратить много времени на создание фиктивных объектов, которые могут не соответствовать реальной реализации.
• Интеграционные / функциональные тесты дополняют модульные тесты, но для их выполнения требуется много времени, поскольку они обычно включают повторную инициализацию всей системы в каждом тесте. (Если вы не выполните повторную инициализацию, среда тестирования будет несовместимой.)
• Рефакторинг или любые другие изменения нарушают множество тестов. Вы тратите много времени на их исправление. Если это вопрос проверки значимых изменений спецификаций, это нормально, но часто тесты ломаются из-за бессмысленных низкоуровневых деталей реализации, а не из-за того, что действительно предоставляет важную информацию. Зачастую настройка фокусируется на переработке внутренних компонентов теста, а не на проверке проверяемой функциональности.
• Полевые отчеты об ошибках не могут быть легко сопоставлены с точной микроверсией кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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