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

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.

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ą).

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.

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).

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.

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.

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.