Як може безперервна доставка працювати на практиці?

Безперервна доставка звучить добре, але мій багаторічний досвід розробки програмного забезпечення говорить про те, що на практиці це не може працювати.

(Редагувати. Щоб зрозуміти, у мене завжди багато тестів, які автоматично працюють. Моє запитання полягає в тому, як отримати впевненість в доставці на кожну реєстрацію, що, наскільки я розумію, є повною формою компакт-диска. Альтернативою є не річні цикли . Ітерації щотижня (які деякі можуть вважати компакт-диск, якщо виконано правильно), два тижні або місяць; включаючи старомодний QA в кінці кожного, доповнюючи автоматизовані тести.)

• Повне покриття тесту неможливо. На кожну дрібницю потрібно витратити багато часу - а час - це гроші. Це цінно, але час можна витратити, сприяючи якості іншими способами.
• Деякі речі важко перевірити автоматично. Наприклад, GUI. Навіть Selenium не скаже вам, чи ваш графічний інтерфейс химерний. Доступ до бази даних важко перевірити без об'ємних світильників, і навіть це не охопить дивні кутові випадки у вашому сховищі даних. Так само безпека та багато іншого. Тільки код бізнес-рівня ефективно перевіряється на одиниці.
• Навіть у бізнес-шарі більшість кодів не є простими функціями, аргументи та повернені значення можна легко виділити для тестових цілей. Ви можете витратити багато часу, будуючи макетні об’єкти, які можуть не відповідати реальним реалізаціям.
• Інтеграційні / функціональні тести доповнюють одиничні тести, але для цього потрібно багато часу, оскільки вони зазвичай передбачають реініціалізацію всієї системи на кожному тесті. (Якщо ви не повторно ініціалізуєтеся, тестове середовище невідповідне.)
• Рефакторинг або будь-які інші зміни проводять безліч тестів. Ви витрачаєте багато часу на їх виправлення. Якщо мова йде про перевірку значущих змін специфікацій, це добре, але часто тести ламаються через безглузді деталі реалізації низького рівня, а не речі, які дійсно надають важливу інформацію. Часто налаштування фокусується на переробці внутрішньої частини тесту, а не на справжній перевірці функціональності, яка тестується.
• Польові звіти про помилки не можна легко зіставити з точною мікроверсією коду.

мій багаторічний досвід розробки програмного забезпечення свідчить, що на практиці це не може працювати.

Ви пробували? Ми з Дейвом написали книгу, грунтуючись на багаторічному колективному досвіді, як нас самих, так і інших старших людей в ThoughtWorks, насправді роблячи те, що ми обговорюємо. Ніщо в книзі не спекулятивне. Все, що ми обговорюємо, було випробувано і перевірено навіть на великих, розподілених проектах. Але ми не радимо приймати це на віру. Звичайно, ви повинні спробувати самостійно. Будь ласка, напишіть, що ви знайдете, а що - ні, включаючи відповідний контекст, щоб інші могли дізнатися з вашого досвіду.

Безперервна доставка має велику увагу на автоматизованому тестуванні. Ми про це витрачаємо близько 1/3 книги. Ми робимо це тому, що альтернатива - тестування вручну - дороге і схильне до помилок, і насправді не є чудовим способом побудови програмного забезпечення високої якості (як сказав Демінг: "Припиніть залежність від масової перевірки для досягнення якості. Покращіть процес і введіть якість в продукт в першу чергу ")

Повне покриття тесту неможливо. На кожну дрібницю потрібно витратити багато часу - а час - це гроші. Це цінно, але час можна витратити, сприяючи якості іншими способами.

Звичайно, повне покриття тесту неможливо, але яка альтернатива: нульове покриття тесту? Є компроміс. Десь між ними - правильна відповідь для вашого проекту. Ми вважаємо, що загалом слід сподіватися витратити близько 50% свого часу на створення або підтримку автоматизованих тестів. Це може здатися дорогим, поки ви не врахуєте вартість всебічного ручного тестування та виправлення помилок, які виходять із користувачів.

Деякі речі важко перевірити автоматично. Наприклад, GUI. Навіть Selenium не скаже вам, чи ваш графічний інтерфейс химерний.

Звичайно. Ознайомтеся з тестовим квадратом Брайана Маріка. Ще потрібно виконувати дослідницьке тестування та тестування на зручність використання вручну. Але саме для цього ви повинні використовувати дорогих і цінних людей - не тестування регресії. Ключовим моментом є те, що вам потрібно встановити конвеєр розгортання, щоб вам було лише заважати виконувати дорогі ручні перевірки проти збірок, які пройшли повний набір автоматизованих тестів. Таким чином, ви зменшуєте кількість грошей, які ви витрачаєте на тестування вручну, і кількість помилок, які коли-небудь роблять це для ручного тестування або виготовлення (до цього часу їх дуже дорого виправити). Автоматичне тестування, зроблене правильно, значно дешевше протягом життєвого циклу продукту, але, звичайно, це капітальні витрати, які амортизують себе з часом.

Доступ до бази даних важко перевірити без об'ємних світильників, і навіть це не охопить дивні кутові випадки у вашому сховищі даних. Так само безпека та багато іншого. Тільки код бізнес-рівня ефективно перевіряється на одиниці.

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

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

Звичайно автоматизовані тести коштують дорого, якщо ви погано будуєте програмне забезпечення та свої тести. Я настійно рекомендую ознайомитись із книжкою "зростаюче об'єктно-орієнтоване програмне забезпечення, керуючись тестами", щоб зрозуміти, як це зробити правильно, щоб ваші тести та код були досяжними з часом.

Інтеграційні / функціональні тести доповнюють одиничні тести, але для цього потрібно багато часу, оскільки вони зазвичай передбачають реініціалізацію всієї системи на кожному тесті. (Якщо ви не повторно ініціалізуєтеся, тестове середовище невідповідне.)

Один із продуктів, над якими я працював, має набір з 3500 тестів прийняття, які тривають до кінця. Ми проводимо його паралельно по сітці з 70 коробок і отримуємо зворотній зв'язок через 45м. Але все-таки довше, ніж ідеал, і саме тому ми виконуємо його як другий етап у конвеєрі після того, як за кілька хвилин пройшли одиничні випробування, тому ми не витрачаємо свої ресурси на склад, на якому у нас немає базового рівня впевненість у.

Рефакторинг або будь-які інші зміни проводять безліч тестів. Ви витрачаєте багато часу на їх виправлення. Якщо мова йде про перевірку значущих змін специфікацій, це добре, але часто тести ламаються через безглузді деталі реалізації низького рівня, а не речі, які дійсно надають важливу інформацію. Часто налаштування фокусується на переробці внутрішньої частини тесту, а не на справжній перевірці функціональності, яка тестується.

Якщо ваш код і тести добре інкапсульовані і вільно з'єднані, рефакторинг не порушить багато тестів. У нашій книзі ми описуємо, як зробити те ж саме і для функціональних тестів. Якщо ваші тести на прийняття ламаються, це знак того, що вам не вистачає одного або декількох одиничних тестів, тому частина компакт-диска передбачає постійне вдосконалення покриття тесту, щоб спробувати знайти помилки раніше в процесі доставки, коли тести будуть більш дрібними та помилки дешевше виправити.

Польові звіти про помилки не можна легко зіставити з точною мікроверсією коду.

Якщо ви тестируете і відпускання частіше (частина точки CD) , то це відносно просто визначити зміна , яке викликало помилку. Вся суть CD полягає в оптимізації циклу зворотного зв’язку, щоб ви могли ідентифікувати помилки якомога швидше після їх реєстрації до контролю версій - і, справді, бажано, перш ніж їх перевірити (саме тому ми запускаємо тести збірки та блоку перед заїздом).

По-перше, компакт-диск має одну велику психічну корекцію - ви повинні визнати, що іноді все вийде з ладу незалежно від того, чим займаєтесь. Зрештою, ви не можете довести негатив.

Після того, як ви пройдете це, ви зрозумієте, що вам потрібні інструменти та процедури, щоб: a) вловлювати ці помилки дуже швидко; б) або відкотити назад, або розгорнути оновлення дуже ефективно. Більше того, якщо ви справді п'єте коктейль CD, ви дійсно доставляєте безліч дрібних, загострених змін, які легко відкотити назад і не мають змоги впроваджувати основні помилки, що стосуються додатків. Навіть хлопці, які справді практикують компакт-диск, обробляють основні зміни традиційним чином.

Кожна система має ризики, і кожен ризик має потенційні витрати. Якщо вартість деякого крихітного ризику, який може зайняти кілька місяців або років, щоб знайти обширне тестування та контроль якості, досить високий (програмне забезпечення у вашому кардіостимуляторі), ви не доставляєте без великого періоду тестування заморожений випуск. Якщо вартість відмови досить мала, можливо, ви постійно постачаєтесь з нульовим тестуванням (сторінка вашої кішки у Facebook).

Повне покриття тесту неможливо. На кожну дрібницю потрібно витратити багато часу - а час - це гроші. Це цінно, але час можна витратити, сприяючи якості іншими способами.

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

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

Однак доступ до бази даних є тривіальним для запису. Вам не потрібно багато тестів на рівні даних, оскільки це лише отримання та налаштування даних. Найголовніше - це забезпечити те, що коли вона не працює, вона відкидається і записує проблему, щоб ви могли її виправити.

Так само безпека та багато іншого. Тільки код бізнес-рівня ефективно перевіряється на одиниці. Навіть у бізнес-шарі більшість кодів не є простими функціями, аргументи та повернені значення можна легко виділити для тестових цілей.

Тоді багато ваших функцій / класів занадто великі. Вони повинні бути написані для перевірки.

Ви можете витратити багато часу, будуючи макетні об’єкти, які можуть не відповідати реальним реалізаціям.

Введення / вивід об'єкта макету повинен відповідати очікуваному. Що відбувається всередині нього неважливо.

Інтеграційні / функціональні тести доповнюють одиничні тести, але для цього потрібно багато часу, оскільки вони зазвичай передбачають реініціалізацію всієї системи на кожному тесті. (Якщо ви не повторно ініціалізуєтеся, тестове середовище невідповідне.)

Вони не повинні працювати весь час. Так само, як потрібно.

Рефакторинг або будь-які інші зміни проводять безліч тестів. Ви витрачаєте багато часу на їх виправлення. Якщо мова йде про перевірку значущих змін специфікацій, це добре, але часто тести ламаються через безглузді деталі реалізації низького рівня, а не речі, які дійсно надають важливу інформацію. Часто налаштування фокусується на переробці внутрішньої частини тесту, а не на справжній перевірці функціональності, яка тестується.

Тоді ваш код занадто щільно пов'язаний, і ваші тести погано написані.

Польові звіти про помилки не можна легко зіставити з точною мікроверсією коду.

Не впевнені, що ви тут отримуєте? Якщо є помилка, напишіть тест, щоб показати, що існує, а потім виправте це.

Для нас добре працює, але наші клієнти переважно внутрішні. Кілька побудов, що робляться протягом дня, зламані збірки не допускаються, використовується механізм веб-запуску, щоб користувачі отримували останню версію кожного запуску. Одна справа, що компакт-диск створює багато проблем. Так, у вас постійно виникають проблеми сумісності, однак, оскільки ви кожного разу вводите лише невеликі зміни, вирішити проблеми дуже просто. Рівень напруги CD набагато нижчий, ніж коли ми проводили великі оновлення, і довелося сподіватися, що все було правильно, оскільки було б так багато коду для перегляду у випадку поломки.

Якщо чесно, ВСЕ програмне забезпечення постійно постачається! Найголовніше - це дістати його з дверей! Отримайте ваші користувачі з його використання та визначте пріоритетні запити на функції та усунення помилок після цього.

"Справжні артисти"
- Стів Джобс.