PODSTAWY Problem dostarczania oprogramowania Niektóre powszechnie występujące błędne wzorce wydawania oprogramowania Antywzorzec: ręczne wdrażanie oprogramowania Antywzorzec: wdrożenie w środowisku zbliżonym do środowiska produkcyjnego dopiero po zakończeniu programowania Antywzorzec: ręczne zarządzanie konfiguracją środowiska produkcyjnego Czy możemy to poprawić? Jak mamy osiągnąć nasz cel? Każda zmiana powinna uruchamiać proces pozyskiwania informacji zwrotnej Informacja zwrotna musi być uzyskiwana możliwie szybko Zespół odpowiedzialny za wdrożenie musi wyciągnąć praktyczne wnioski z otrzymanej informacji zwrotnej Czy ten proces się skaluje? Jakie płyną z tego korzyści? Przyznanie zespołom większej władzy Ograniczenie liczby błędów Obniżenie poziomu stresu Elastyczność wdrożenia Ćwiczenie czyni mistrza Kandydat do wydania Każde zaewidencjonowanie prowadzi do potencjalnego wydania Zasady dostarczania oprogramowania Stwórz powtarzalny, niezawodny proces dostarczania oprogramowania Automatyzuj, co tylko się da Przechowuj wszystko w systemie kontroli wersji Jeśli to boli, rób to częściej i szybciej zmierz się z bólem Wbuduj jakość w proces wytwarzania Gotowe oznacza wydane Wszyscy są odpowiedzialni za udostępnianie oprogramowania Ciągłe doskonalenie Zarządzanie konfiguracją Stosowanie systemów kontroli wersji W systemie kontroli wersji przechowuj absolutnie wszystko Wprowadzaj zmiany regularnie do głównej gałęzi projektu Posługuj się czytelnymi opisami zakresu zmian Zarządzanie zależnościami Zarządzanie bibliotekami zewnętrznymi Zarządzanie modułami Zarządzanie konfiguracją oprogramowania Konfiguracja i elastyczność Typy konfiguracji Zarządzanie konfiguracją aplikacji Zarządzanie konfiguracją szeregu aplikacji Zasady zarządzania konfiguracją aplikacji Zarządzanie środowiskami Narzędzia do zarządzania środowiskami Zarządzanie procesem zmiany Ciągła integracja Wdrażanie ciągłej integracji Czego potrzebujesz na początek? Podstawowy system ciągłej integracji Warunki wstępne ciągłej integracji Ewidencjonuj regularnie Stwórz obszerny i kompleksowy zestaw zautomatyzowanych testów Niech proces kompilacji i testowania będzie możliwie krótki Zarządzanie środowiskiem programistycznym Stosowanie systemów ciągłej integracji Podstawowa funkcjonalność Wodotryski Kluczowe praktyki Nie ewidencjonuj niczego w popsutej kompilacji Zawsze testuj lokalnie wszystkie zmiany przed ich zatwierdzeniem albo zleć to serwerowi CI Zanim podejmiesz pracę, poczekaj na powodzenie testów towarzyszących przekazywaniu zmian Nigdy nie idź do domu, dopóki kompilacja nie działa poprawnie Zawsze bądź przygotowany na powrót do poprzednich wersji Ustaw sobie limit czasu na poprawki przed cofnięciem zmian Nie wyłączaj testów, które zakończyły się niepowodzeniem Weź odpowiedzialność za wszystkie szkody powstałe w wyniku zmian Programowanie sterowane testami Zalecane praktyki Praktyki programowania ekstremalnego (XP) Odrzucanie kompilacji ze względu na naruszenie architektury Odrzucanie kompilacji ze względu na powolność testów Odrzucanie kompilacji ze względu na ostrzeżenia i niewłaściwe formatowania kodu Zespoły rozproszone Wpływ na proces Scentralizowana ciągła integracja Problemy techniczne Podejścia alternatywne Rozproszone systemy kontroli wersji Wdrożenie strategii testów Typy testów Testy biznesowe wspierające proces wytwarzania oprogramowania Testy technologiczne wspierające programowanie Testy biznesowe umożliwiające krytyczną analizę projektu Testy technologiczne umożliwiające krytyczną analizę projektu Obiekty zastępcze Sytuacje i strategie z prawdziwego życia Na początku projektu W środku projektu Kod zastany Testy integracyjne Proces Zarządzanie zaległymi błędami POTOK WDROŻEŃ Anatomia potoku wdrożeń Czym jest potok wdrożeń? Podstawowy potok wdrożeń Praktyki związane z potokiem wdrożeń Kompiluj binaria tylko raz W każdym środowisku wdrażaj w taki sam sposób Testuj wdrożenia testami dymnymi Wdrażaj na kopii środowiska produkcyjnego Każda zmiana powinna być natychmiast przekazywana do kolejnej fazy potoku Jeśli jakakolwiek część potoku nie działa, zatrzymaj potok Faza przekazywania zmian Najlepsze praktyki fazy przekazywania zmian Bramka automatycznych testów akceptacyjnych Najlepsze praktyki fazy zautomatyzowanych testów akceptacyjnych Kolejne fazy testowania Testy ręczne Testy niefunkcjonalne Przygotowanie do wydania Automatyzacja wdrożenia i wydania Wycofywanie się ze zmian Budowanie na sukcesie Implementacja potoku wdrożeń Tworzenie modelu strumienia wartości i szkieletu systemu Automatyzacja procesu kompilacji i wdrażania Automatyzacja testów jednostkowych i analiza kodu Automatyzacja testów akceptacyjnych Rozwijanie potoku Miary Skrypty kompilacji i wdrożenia Przegląd narzędzi kompilacji Make Ant NAnt i MSBuild Maven Rake Buildr Psake Reguły i praktyki pisania skryptów kompilacji i wdrożenia Stwórz skrypt dla każdej fazy potoku wdrożeń Zastosuj właściwą technologię do wdrożenia aplikacji W każdym środowisku wdrażaj za pomocą tych samych skryptów Skorzystaj z systemu zarządzania pakietami systemu operacyjnego Zapewnij idempotentność procesu wdrożenia Rozwijaj system wdrożeniowy przyrostowo Struktura projektu dla aplikacji, których celem jest wirtualna maszyna Javy Układ projektu Tworzenie skryptów wdrożenia Wdrażanie i testowanie warstw Testowanie konfiguracji środowiska Rady i wskazówki Zawsze stosuj ścieżki względne Wyeliminuj etapy ręczne Wbuduj możliwość prześledzenia drogi od binariów do systemu kontroli wersji Nie ewidencjonuj binariów w systemie kontroli wersji jako części kompilacji Cele testowe nie powinny eliminować kompilacji Ogranicz aplikację za pomocą zintegrowanych testów dymnych Porady i wskazówki dotyczące .NET Faza przekazywania zmian Zasady i praktyki fazy przekazywania zmian Dostarczaj szybkiej i użytecznej informacji zwrotnej Co powinno przerywać fazę przekazywania zmian? Nadzoruj uważnie fazę przekazywania zmian Przekaż odpowiedzialność programistom W bardzo dużych zespołach przypisz komuś funkcję mistrza kompilacji Wyniki fazy przekazywania zmian Repozytorium artefaktów Zasady i praktyki dotyczące zestawu testów fazy przekazywania zmian Unikaj interfejsu użytkownika Stosuj wstrzykiwanie zależności Unikaj bazy danych Przy testach jednostkowych unikaj asynchroniczności Wykorzystywanie obiektów zastępczych Minimalizacja stanu w testach Pozorowanie czasu Nic na siłę Zautomatyzowane testy akceptacyjne Dlaczego zautomatyzowane testy akceptacyjne są tak ważne?) Jak tworzyć zestawy poddających się utrzymaniu testów akceptacyjnych? Testowanie graficznego interfejsu użytkownika Tworzenie testów akceptacyjnych Rola analityków i testerów Analiza w projektach iteracyjnych Kryteria akceptacyjne jako wykonywalne specyfikacje Warstwa sterownika aplikacji Jak wyrażać swoje kryteria akceptacyjne? Wzorzec sterownika okna: uniezależnianie testów od GUI Implementacja testów akceptacyjnych Stan w testach akceptacyjnych Ograniczenia procesu, hermetyzacja i testowanie Zarządzanie asynchronicznością i przekroczeniem czasu przyznanego na daną operację Stosowanie obiektów zastępczych Faza testów akceptacyjnych Utrzymywanie poprawności testów akceptacyjnych Testy wdrożenia Wydajność testów akceptacyjnych Refaktoryzacja często wykonywanych zadań Współdziel kosztowne zasoby Testowanie równoległe Stosowanie przetwarzania rozproszonego Testowanie wymagań niefunkcjonalnych Zarządzanie wymaganiami niefunkcjonalnymi Analiza wymagań niefunkcjonalnych Programowanie z myślą o wydajności Pomiar wydajności Jak definiować sukces i porażkę w testach wydajnościowych? Środowisko testów wydajnościowych Automatyzacja testów wydajnościowych Testowanie wydajności poprzez interfejs użytkownika Nagrywanie interakcji przez usługę lub publiczne API Stosowanie szablonów nagranych interakcji Stosowanie stubów testów wydajnościowych do produkcji testów Dodawanie testów wydajnościowych do potoku wdrożeń Dodatkowe korzyści płynące z systemu testów wydajnościowych Wdrażanie i wydawanie aplikacji Tworzenie strategii udostępniania oprogramowania Plan wydania Udostępnianie produktów użytkownikom Wdrażanie i promocja aplikacji Pierwsze wdrożenie Szkicowanie procesu udostępniania oprogramowania i promowania kompilacji Promocja konfiguracji Orkiestracja Wdrożenia w środowiskach tymczasowych Wycofywanie się z wdrożeń i wydania bez przestojów Wycofywanie się poprzez powtórne wdrożenie wcześniejszej dobrej wersji Wydanie bez przestoju Wdrożenia niebiesko-zielone Wydanie kanarkowe Poprawki awaryjne Ciągłe wdrażanie Ciągłe udostępnianie oprogramowania instalowanego przez użytkownika Rady i wskazówki Ludzie odpowiedzialni za wdrożenie powinni być zaangażowani w tworzenie procesu wdrożenia Loguj działania związane z wdrożeniem Nie kasuj starych plików, tylko je przenieś Za wdrożenie odpowiada cały zespół Aplikacje serwerowe nie powinny mieć interfejsu graficznego Przy nowym wdrożeniu pamiętaj o rozgrzewce Szybko odrzucaj błędne wersje Nie dokonuj zmian bezpośrednio w środowisku produkcyjnym EKOSYSTEM DOSTARCZANIA OPROGRAMOWANIA Zarządzanie środowiskami i infrastrukturą Rozumienie potrzeb zespołu eksploatacji systemów IT Dokumentacja i audyt Ostrzeżenia o nienormalnych zdarzeniach Planowanie ciągłości dostarczania usług IT Korzystaj z technologii znanej zespołowi eksploatacji systemów IT Opracowywanie modelu infrastruktury i zarządzanie nią Kontrola dostępu do infrastruktury Wprowadzanie zmian w infrastrukturze Zarządzanie dostarczaniem i konfiguracją serwerów Dostarczanie serwerów Bieżące zarządzanie serwerami Zarządzanie konfiguracją middleware'u Zarządzanie konfiguracją Zbadaj produkt Przeanalizuj, w jaki sposób middleware obsługuje stan Poszukaj API konfiguracji Zastosuj lepszą technologię Zarządzanie usługami infrastrukturalnymi Systemy wieloadresowe Wirtualizacja Zarządzanie środowiskami wirtualnymi Środowiska wirtualne i potok wdrożeń Wysoce równoległe testowanie ze środowiskami wirtualnymi Przetwarzanie w chmurze Infrastruktura w chmurze Platformy w chmurze Jedno rozwiązanie nie musi być odpowiednie dla wszystkich Krytyka przetwarzania w chmurze Monitorowanie infrastruktury i aplikacji Gromadzenie danych Rejestrowanie zdarzeń Tworzenie tablic wskaźników Monitoring sterowany zachowaniami Zarządzanie danymi Pisanie skryptów baz danych Inicjalizacja baz danych Zmiana przyrostowa Wersjonowanie bazy danych Zarządzanie zharmonizowanymi zmianami Wycofywanie się do poprzedniej wersji baz danych i wydania bez przestojów Wycofywanie się bez utraty danych Uniezależnianie wdrożenia aplikacji od migracji bazy danych Zarządzanie danymi testowymi Imitowanie bazy danych na potrzeby testów jednostkowych Zarządzanie zależnościami między testami a danymi Izolacja testu Przygotowanie i rozmontowanie Spójne scenariusze testowe Zarządzanie danymi i potok wdrożeń Dane w fazie przekazywania zmian Dane w testach akceptacyjnych Dane w testach wydajnościowych Dane w innych fazach testów Zarządzanie modułami i zależnościami Utrzymywanie aplikacji w stanie zdatności do wydania Ukryj nową funkcjonalność, dopóki nie zostanie ukończona Wprowadzaj wszystkie zmiany przyrostowo Rozgałęzianie przez abstrakcję Zależności Piekło zależności Zarządzanie bibliotekami Moduły Jak dzielić bazę kodu na moduły? Droga modułów przez potok wdrożeń Potok integracyjny Zarządzanie schematem zależności Tworzenie schematów zależności Potokowanie schematów zależności Kiedy powinniśmy wyzwalać kompilacje? Ostrożny optymizm Zależności cykliczne Zarządzanie binariami Jak powinno działać repozytorium artefaktów? W jaki sposób potok wdrożeń powinien współdziałać z repozytorium artefaktów? Zarządzanie zależnościami za pomocą Mavena Refaktoryzacja zależności Mavena Zaawansowana kontrola wersji Krótka historia kontroli wersji CVS Subversion Komercyjne systemy kontroli wersji Wyłącz pesymistyczne blokowanie Rozgałęzianie i scalanie Scalanie Gałęzie, strumienie i ciągła integracja Rozproszone systemy kontroli wersji Czym jest rozproszony system kontroli wersji? Krótka historia rozproszonego systemu kontroli wersji Rozproszone systemy kontroli wersji w środowiskach korporacyjnych Korzystanie z rozproszonych systemów kontroli wersji Strumieniowe systemy kontroli wersji Czym są strumieniowe systemy kontroli wersji? Modele wytwarzania oprogramowania z wykorzystaniem strumieni Widoki statyczne i dynamiczne Ciągła integracja z systemami kontroli wersji opartymi na strumieniach Programuj na gałęzi głównej projektu Dokonywanie złożonych zmian bez rozgałęziania Gałąź na potrzeby wydania Rozgałęzienia według kryterium funkcji Rozgałęzianie pod kątem zespołu Zarządzanie ciągłym dostarczaniem oprogramowania Model dojrzałości zarządzania konfiguracją i wydaniami Jak posługiwać się modelem dojrzałości Cykl życia projektu Identyfikacja Zapoczątkowywanie Inicjalizacja Wytwarzanie i wdrażanie Eksploatacja Proces zarządzania ryzykiem Podstawy zarządzania ryzykiem Harmonogram zarządzania ryzykiem Jak wykonać ćwiczenie z zakresu zarządzania ryzykiem? Częste problemy z dostarczaniem oprogramowania - objawy i przyczyny Rzadkie lub wadliwe wdrożenia Kiepska jakość aplikacji Kiepsko zarządzany proces ciągłej integracji Słabe zarządzanie konfiguracją Zgodność z regulacjami i audyt Przewaga automatyzacji nad dokumentacją Narzucanie możliwości śledzenia zmian Praca w silosach Zarządzanie zmianą