Jak w praktyce może działać ciągła dostawa?

22

Ciągła dostawa brzmi dobrze, ale moje wieloletnie doświadczenie w tworzeniu oprogramowania sugeruje, że w praktyce nie może działać.

(Edytuj: Żeby było jasne, zawsze mam wiele testów uruchamianych automatycznie. Moje pytanie dotyczy tego, jak zdobyć pewność przy każdym zameldowaniu, co rozumiem, że jest to pełna wersja płyty CD. Alternatywą nie są cykle roczne Są to iteracje co tydzień (które niektórzy mogą uważać za wciąż CD, jeśli są wykonane poprawnie), dwa tygodnie lub miesiące; w tym staromodna kontrola jakości na końcu każdego z nich, uzupełniająca zautomatyzowane testy.)

  • Pełny zasięg testu jest niemożliwy. Musisz poświęcić dużo czasu - a czas to pieniądz - na każdą drobiazg. Jest to cenne, ale czas można poświęcić na poprawę jakości na inne sposoby.
  • Niektóre rzeczy są trudne do przetestowania automatycznie. Np. GUI. Nawet Selenium nie powie ci, czy twój GUI jest dziwny. Dostęp do bazy danych jest trudny do przetestowania bez nieporęcznych urządzeń, a nawet to nie obejmie dziwnych narożnych przypadków w pamięci masowej. Podobnie bezpieczeństwo i wiele innych rzeczy. Tylko kod warstwy biznesowej można skutecznie przetestować jednostkowo.
  • Nawet w warstwie biznesowej większość kodu nie jest prostymi funkcjami, których argumenty i zwracane wartości można łatwo izolować do celów testowych. Możesz spędzać dużo czasu na budowaniu fałszywych obiektów, które mogą nie odpowiadać rzeczywistym implementacjom.
  • Testy integracyjne / funkcjonalne uzupełniają testy jednostkowe, ale ich uruchomienie zajmuje dużo czasu, ponieważ zazwyczaj wymagają ponownego zainicjowania całego systemu w każdym teście. (Jeśli nie zainicjujesz ponownie, środowisko testowe jest niespójne.)
  • Refaktoryzacja lub wszelkie inne zmiany psują wiele testów. Spędzasz dużo czasu na ich naprawianiu. Jeśli chodzi o sprawdzanie znaczących zmian specyfikacji, to dobrze, ale często testy są przerywane z powodu bezsensownych szczegółów implementacyjnych niskiego poziomu, a nie rzeczy, które naprawdę dostarczają ważnych informacji. Często poprawianie koncentruje się na przerobieniu wewnętrznych elementów testu, a nie na prawdziwym sprawdzaniu testowanej funkcjonalności.
  • Raporty terenowe dotyczące błędów nie mogą być łatwo dopasowane do precyzyjnej mikro-wersji kodu.
Joshua Fox
źródło
Działa bardzo dobrze dla Etsy slideshare.net/OReillyOSCON/... !
YoTsumi,
4
Ciągła dostawa nie wymaga testowania (ale pomaga). Odnosi się do faktu, że rzeczy, które budujesz regularnie, MOGĄ zostać wysłane do klienta w razie potrzeby.
Interesujące jest to, że twoje zastrzeżenia do ciągłego dostarczania koncentrują się w przeważającej mierze na testowaniu jako element CD. Jest to jednak tylko jedna część układanki: potrzebujesz kompetentnego wewnętrznego oprzyrządowania, programiści zobowiązani do rygorystycznych kontroli jakości, szeroko zakrojonego podejścia do ustalania priorytetów w automatycznych testach, nie wspominając o silnym wsparciu organizacyjnym. Można to zrobić, ale wiele osób musi zaangażować się w sprawę.
Stephen Gross
1
@Stephen Tak, koncentruję się na testowaniu, ponieważ zgadzam się co do wszystkich innych aspektów. Jestem też za testowaniem. Po prostu nie rozumiem, jak możesz mieć wystarczającą pewność siebie, aby wdrożyć każde zameldowanie.
Joshua Fox,
@ Thorbjørn Ravn Andersen. Oczywiście CD wydaje się wymagać testowania. Jak możesz mieć pewność, że automatycznie wyślesz każde zameldowanie bez niego?
Joshua Fox,

Odpowiedzi:

29

moje wieloletnie doświadczenie w tworzeniu oprogramowania sugeruje, że w praktyce nie może ono działać.

Próbowałeś tego? Dave i ja napisaliśmy książkę na podstawie wielu wspólnych lat doświadczeń, zarówno nas samych, jak i innych starszych osób w ThoughtWorks, faktycznie wykonując rzeczy, które omawiamy. Nic w książce nie spekuluje. Wszystko, co omawiamy, zostało wypróbowane i przetestowane nawet w dużych, rozproszonych projektach. Ale nie sugerujemy, abyście przyjmowali to na wiarę. Oczywiście powinieneś spróbować sam i napisz, co znajdujesz, a co nie, w tym odpowiedni kontekst, aby inni mogli uczyć się na podstawie twoich doświadczeń.

Continuous Delivery kładzie duży nacisk na automatyczne testy. Mówimy o tym w około 1/3 książki. Robimy to, ponieważ alternatywa - testowanie ręczne - jest droga i podatna na błędy, a właściwie nie jest to świetny sposób na tworzenie wysokiej jakości oprogramowania (jak powiedziała Deming: „Przestań polegać na masowej inspekcji w celu uzyskania jakości. Popraw proces i wbuduj jakość w produkt w pierwszej kolejności ”)

Pełny zasięg testu jest niemożliwy. Musisz poświęcić dużo czasu - a czas to pieniądz - na każdą drobiazg. Jest to cenne, ale czas można poświęcić na poprawę jakości na inne sposoby.

Oczywiście pełne pokrycie testowe jest niemożliwe, ale jaka jest alternatywa: zerowe pokrycie testowe? Występuje kompromis. Gdzieś pomiędzy znajduje się poprawna odpowiedź dla twojego projektu. Uważamy, że ogólnie należy spodziewać się, że spędzisz około 50% swojego czasu na tworzeniu lub utrzymywaniu automatycznych testów. To może wydawać się drogie, dopóki nie weźmiesz pod uwagę kosztu kompleksowych testów ręcznych i naprawiania błędów, które trafiają do użytkowników.

Niektóre rzeczy są trudne do przetestowania automatycznie. Np. GUI. Nawet Selenium nie powie ci, czy twój GUI jest dziwny.

Oczywiście. Sprawdź kwadrant testowy Briana Maricka. Nadal musisz ręcznie przeprowadzić testy eksploracyjne i testy użyteczności. Ale do tego powinieneś używać drogich i cennych ludzi - a nie testów regresyjnych. Kluczem jest to, że musisz zainstalować potok wdrażania, abyś zawracał sobie głowę uruchamianiem drogich ręcznych sprawdzeń poprawności względem kompilacji, które przeszły kompleksowy zestaw automatycznych testów. W ten sposób zmniejszacie zarówno ilość pieniędzy, które wydajecie na ręczne testowanie, jak i liczbę błędów, które kiedykolwiek trafiły do ​​ręcznego testowania lub produkcji (do tego czasu naprawienie ich jest bardzo drogie). Zautomatyzowane testy wykonane prawidłowo są znacznie tańsze w całym cyklu życia produktu, ale oczywiście są to nakłady inwestycyjne, które amortyzują się z czasem.

Dostęp do bazy danych jest trudny do przetestowania bez nieporęcznych urządzeń, a nawet to nie obejmie dziwnych narożnych przypadków w pamięci masowej. Podobnie bezpieczeństwo i wiele innych rzeczy. Tylko kod warstwy biznesowej można skutecznie przetestować jednostkowo.

Dostęp do bazy danych jest niejawnie testowany przez kompleksowe testy akceptacji funkcjonalnej oparte na scenariuszu. Bezpieczeństwo będzie wymagało połączenia testów automatycznych i ręcznych - automatycznych testów penetracyjnych i analizy statycznej w celu wykrycia (np.) Przekroczenia bufora.

Nawet w warstwie biznesowej większość kodu nie jest prostymi funkcjami, których argumenty i zwracane wartości można łatwo izolować do celów testowych. Możesz spędzać dużo czasu na budowaniu fałszywych obiektów, które mogą nie odpowiadać rzeczywistym implementacjom.

Oczywiście testy automatyczne są drogie, jeśli źle zbudujesz swoje oprogramowanie i testy. Zdecydowanie polecam przeczytanie książki „rosnące oprogramowanie obiektowe oparte na testach”, aby dowiedzieć się, jak zrobić to dobrze, aby z czasem utrzymać testy i kod.

Testy integracyjne / funkcjonalne uzupełniają testy jednostkowe, ale ich uruchomienie zajmuje dużo czasu, ponieważ zazwyczaj wymagają ponownego zainicjowania całego systemu w każdym teście. (Jeśli nie zainicjujesz ponownie, środowisko testowe jest niespójne.)

Jeden z produktów, nad którymi pracowałem, zawiera pakiet 3500 kompleksowych testów akceptacyjnych, których uruchomienie zajmuje 18 godzin. Prowadzimy go równolegle na siatce 70 skrzynek i otrzymujemy informacje zwrotne w odległości 45 metrów. Wciąż dłużej niż ideał, dlatego uruchamiamy go jako drugi etap w przygotowaniu po testach jednostkowych w ciągu kilku minut, więc nie marnujemy naszych zasobów na kompilację, w której nie mamy podstawowego poziomu zaufanie do.

Refaktoryzacja lub wszelkie inne zmiany psują wiele testów. Spędzasz dużo czasu na ich naprawianiu. Jeśli chodzi o sprawdzanie znaczących zmian specyfikacji, to dobrze, ale często testy są przerywane z powodu bezsensownych szczegółów implementacyjnych niskiego poziomu, a nie rzeczy, które naprawdę dostarczają ważnych informacji. Często poprawianie koncentruje się na przerobieniu wewnętrznych elementów testu, a nie na prawdziwym sprawdzaniu testowanej funkcjonalności.

Jeśli kod i testy są dobrze zamknięte i luźno powiązane, refaktoryzacja nie przerwie wielu testów. W naszej książce opisujemy, jak zrobić to samo w przypadku testów funkcjonalnych. Jeśli testy akceptacyjne się zepsują, oznacza to, że brakuje jednego lub więcej testów jednostkowych, więc część płyty CD wymaga ciągłego ulepszania zakresu testów, aby próbować znaleźć błędy wcześniej w procesie dostarczania, w którym testy są bardziej szczegółowe i błędy są tańsze do naprawienia.

Raporty terenowe dotyczące błędów nie mogą być łatwo dopasowane do precyzyjnej mikro-wersji kodu.

Jeśli testujesz i częściej zwalniania (część punktu CD), to jest stosunkowo proste do zidentyfikowania zmian, który spowodował błąd. Celem CD jest optymalizacja cyklu sprzężenia zwrotnego, abyś mógł zidentyfikować błędy tak szybko, jak to możliwe po ich sprawdzeniu w kontroli wersji - i rzeczywiście najlepiej przed ich zalogowaniem (dlatego przeprowadzamy testy kompilacji i testów jednostkowych przed odprawą).

Jez Humble
źródło
Dzięki za odpowiedź. Tak, wierzę w testowanie. Moje projekty mają dobre pokrycie kodu z automatycznych testów przeprowadzanych przy codziennej kompilacji. Mówię tylko, że potrzebujesz wersji przed wydaniem. „Nadal musisz przeprowadzić testy eksploracyjne ... ręcznie”. Nie rozumiem. Pełny system CD wdraża się przy każdym zameldowaniu. Jak to zrobić, jeśli włączysz testowanie ręczne?
Joshua Fox,
3
Lubię rozróżniać między ciągłą dostawą a ciągłym wdrażaniem. Oto różnica. Ciągła dostawa oznacza, że ​​system jest zawsze gotowy do produkcji i można go zwolnić na żądanie za naciśnięciem jednego przycisku. Wydanie jest decyzją biznesową. Ciągłe wdrażanie jest ograniczającym przypadkiem, w którym wypuszczasz każdą dobrą kompilację (pamiętaj, że nie każde odprawy - niektóre odprawy nie dają wersji, którą można wydać). W obu przypadkach można dołączyć ręczne sprawdzanie poprawności: kluczem jest koncepcja potoku wdrażania .
Jez Humble,
Odnośnie do „Dostępu do bazy danych testuje się domyślnie za pomocą kompleksowych testów akceptacji funkcjonalnej opartych na scenariuszu”. Kluczowym problemem jest to, że jest to domniemane . Ludzie wydają się z tego zadowoleni, ale jest to bardzo marnujące czas podejście; zamiast mówić problem „Tego oczekiwałem po DB i dostałem to zamiast tego”, napisano: „Coś pękło w jednej ze 100 warstw”.
atoth
11

Po pierwsze, płyta CD wymaga jednej wielkiej korekty mentalnej - trzeba przyznać, że czasem wszystko pójdzie nie tak, jak się stanie. Na koniec dnia nie możesz udowodnić negatywu.

Po obejściu tego zdajesz sobie sprawę, że potrzebujesz narzędzi i procedur, aby a) bardzo szybko wykryć te błędy i b) albo wycofać aktualizację, albo bardzo skutecznie wdrożyć aktualizację. Co więcej, jeśli naprawdę pijesz koktajl CD, naprawdę dostarczasz wiele małych, spiczastych zmian, które są łatwe do wycofania i nie powinny być w stanie wprowadzić poważnych błędów w całej aplikacji. Nawet faceci naprawdę ćwiczący płyty CD dokonują poważnych zmian w bardziej tradycyjny sposób.

Wyatt Barnett
źródło
„małe… zmiany… nie powinny być w stanie wprowadzić błędów dotyczących całej aplikacji”. Może się to zdarzyć nawet w dobrze sklasyfikowanym kodzie. Na przykład dodajesz div, który wypycha inny div z widoku w jednej konkretnej przeglądarce. Na przykład wartość null pojawia się w nieoczekiwanym przypadku narożnika, generując wyjątek i uniemożliwiając wyświetlanie interfejsu GUI. Tak, powinieneś przetestować wszystko, co możliwe, tak jak ja, ale nieuchronnie zdarzają się błędy, a małe błędy mogą zakłócać działanie całej aplikacji.
Joshua Fox,
Ale nadal są łatwe do znalezienia i naprawy, co stanowi większy nacisk.
Wyatt Barnett,
2

Każdy system wiąże się z ryzykiem, a każde ryzyko wiąże się z potencjalnymi kosztami. Jeśli koszt niewielkiego ryzyka, którego znalezienie w rozległych testach i kontroli jakości może zająć miesiące lub lata, jest wystarczająco wysoki (oprogramowanie w rozruszniku serca), nie wysyłamy go bez długiego okresu testowania zamrożone wydanie. Jeśli koszt awarii jest wystarczająco mały, być może wysyłasz ciągle z zerowym testowaniem (strona twojego kota na Facebooku).

hotpaw2
źródło
Tak. W przypadku większości zastosowań produkcyjnych ryzyko leży gdzieś pośrodku. I wydaje mi się, że ryzyko jest takie, że nie chcielibyśmy wdrażać przy każdym meldowaniu, nawet przy automatycznych testach. Wydaje się, że runda kontroli jakości jest zawsze potrzebna. Wydaje mi się jednak, że wydawane są mniej więcej cotygodniowe wydania.
Joshua Fox,
1

Pełny zasięg testu jest niemożliwy. Musisz poświęcić dużo czasu - a czas to pieniądz - na każdą drobiazg. Jest to cenne, ale czas można poświęcić na poprawę jakości na inne sposoby.

Nie potrzebujesz stuprocentowego pokrycia, musisz mieć pewność, że Twój system jest pewny, że zmiany w jednym miejscu nie zepsują rzeczy, które wcześniej sprawdziłeś.

Niektóre rzeczy są trudne do przetestowania automatycznie. Np. GUI. Nawet Selenium nie
powie ci, czy twój GUI jest dziwny. Dostęp do bazy danych jest trudny do przetestowania bez nieporęcznych urządzeń, a nawet to nie obejmie dziwnych narożnych przypadków w pamięci masowej.

Dostęp do bazy danych jest jednak prosty do napisania. Nie powinieneś potrzebować wielu testów na swojej warstwie danych, ponieważ to tylko pobieranie i ustawianie danych. Najważniejszą rzeczą jest upewnienie się, że gdy zawiedzie, wycofuje się i rejestruje problem, abyś mógł go naprawić.

Podobnie bezpieczeństwo i wiele innych rzeczy. Tylko kod warstwy biznesowej można skutecznie przetestować jednostkowo. Nawet w warstwie biznesowej większość kodu nie jest prostymi funkcjami, których argumenty i zwracane wartości można łatwo izolować do celów testowych.

Wówczas wiele twoich funkcji / klas jest zbyt dużych. Powinny być napisane, aby były testowalne.

Możesz spędzać dużo czasu na budowaniu fałszywych obiektów, które mogą nie odpowiadać rzeczywistym implementacjom.

Wejścia / wyjścia próbnego obiektu powinny jednak być zgodne z oczekiwaniami. To, co dzieje się w środku, nie ma znaczenia.

Testy integracyjne / funkcjonalne uzupełniają testy jednostkowe, ale ich uruchomienie zajmuje dużo czasu, ponieważ zazwyczaj wymagają ponownego zainicjowania całego systemu w każdym teście. (Jeśli nie zainicjujesz ponownie, środowisko testowe jest niespójne.)

Nie należy ich uruchamiać przez cały czas. W razie potrzeby.

Refaktoryzacja lub wszelkie inne zmiany psują wiele testów. Spędzasz dużo czasu na ich naprawianiu. Jeśli chodzi o sprawdzanie znaczących zmian specyfikacji, to dobrze, ale często testy są przerywane z powodu bezsensownych szczegółów implementacyjnych niskiego poziomu, a nie rzeczy, które naprawdę dostarczają ważnych informacji. Często poprawianie koncentruje się na przerobieniu wewnętrznych elementów testu, a nie na prawdziwym sprawdzaniu testowanej funkcjonalności.

Wówczas twój kod jest zbyt ściśle powiązany, a twoje testy są źle napisane.

Raporty terenowe dotyczące błędów nie mogą być łatwo dopasowane do precyzyjnej mikro-wersji kodu.

Nie jesteś pewien, o co tu chodzi? Jeśli wystąpi błąd, napisz test, aby pokazać jego istnienie, a następnie napraw go.

CaffGeek
źródło
„We / wy fałszywego obiektu powinno być zgodne z oczekiwaniami”. „Budowanie MO, które w pełni implementują specyfikację interfejsu, jest czasochłonne. Gorzej, należy je stale aktualizować, aby skutecznie pisać cały kod dwa razy (raz do produkcji i raz dla MO)
Joshua Fox
1

Działa dobrze dla nas, ale nasi klienci są głównie wewnętrzni. Wiele kompilacji wykonanych w ciągu dnia, zepsute kompilacje nie są tolerowane, stosowany jest mechanizm uruchamiania sieci, dzięki czemu użytkownicy otrzymują najnowszą wersję przy każdym uruchomieniu. Jedną rzeczą jest to, że CD powoduje wiele problemów. Tak, cały czas masz obawy dotyczące zgodności, jednak ponieważ za każdym razem wdrażasz tylko niewielkie zmiany, problemy są naprawdę łatwe do rozwiązania. Poziom stresu na płycie CD jest DUŻO niższy niż w przypadku dużych aktualizacji i musieliśmy mieć nadzieję, że wszystko jest w porządku, ponieważ w przypadku awarii byłoby tak dużo kodu do sprawdzenia.

Brian Knoblauch
źródło
-4

Szczerze mówiąc, całe oprogramowanie jest w ciągłej dostawie! Najważniejszą rzeczą jest wyciągnięcie go z drzwi! Niech użytkownicy go używają, a następnie ustal priorytety żądań funkcji i usuwania błędów.

„Prawdziwi artyści wysyłają”
- Steve Jobs.

Gary Willoughby
źródło
alternatywą dla płyt CD nie są cykle roczne. To iteracje co tydzień, dwa tygodnie lub miesiące.
Joshua Fox,