Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Few Questions about Continuous Delivery

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 23 Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (14)

Les utilisateurs ont également aimé (20)

Publicité

Similaire à Few Questions about Continuous Delivery (20)

Plus récents (20)

Publicité

Few Questions about Continuous Delivery

  1. 1. Continuous Delivery Code Sprinters http://agileszkolenia.pl   http://fb.com/CodeSprinters   Wiktor Żołnowski http://blog.testowka.pl   http://fb.com/innypunktwidzenianajakosc    Twitter: @streser WE ARE HIRING!! Pragmatic Coders http://pragmaticcoders.com http://fb.com/pragmaticcoders @pragmaticcoders
  2. 2. @strese Continuous Delivery nie polega na ciągłym  dostarczaniu kolejnych wersji  oprogramowania na produkcję... Continuous Delivery to umożliwienie  wydawania nowej wersji oprogramowania  w dowolnym momencie... @streser
  3. 3. @strese Jak dobry jest Twój proces? @streser
  4. 4. @strese Co by się musiało stać by w Twoim  projekcie możliwe było wydawanie go w  dowolnym momencie? @streser
  5. 5. @strese 15 pytań!  Oceń stosowanie danej praktyki w Twojej  firmie w skali 0­5. @streser
  6. 6. @streser 1. Low dependency architecture? ­ czy architektura rozwiązań jest komponentowa? ­ czy komponenty są od siebie niezależne? ­ czy możliwe jest bezpieczne wprowadzanie zmian w  poszczególnych komponentach bez konieczności  testowania całego systemu? ­ czy możliwe jest pisanie testów jednoskowych bez  konieczności mockowania wszystkiego naokoło?
  7. 7. @strese 2. Coding Standards? ­ czy istnieją zdefiniowane i spisane standardy  kodowania? ­ czy wszyscy pracujący nad produktem wiedzą jak te  standardy wyglądają?  ­ czy standardy są przestrzegane w codziennej pracy? ­ czy kod sprawdzany jest pod względem spelnienia  standardów w sposób ciągły (tam gdzie się da  automatycznie? @streser
  8. 8. @strese 3. Desig/Code Review ­ czy każdy kawałek kodu jest przeglądany przez  conajmniej 2 developerów? ­ czy w efekcie Code Review regularnie poprawiana  jest architektura oprogramowania?  ­ czy Code Review jest naturalną częścią ciągłego  procesu a nie dodatkowym etapem gdzieś na końcu  pracy nad poszczególnym wydaniem? @streser
  9. 9. @strese 4. Comprehensive Version Control ­ czy całość kodu jest wersjonowana? ­ czy wersjonowane są również artefakty takie jak na  przykład pliki wykonywalne? ­ czy wersjonowana jest konfiguracja? ­ czy wersjonowana jest struktura danych? ­ czy wersjonowane jest środowisko (biblioteki, wersje  systemu etc.)? ­ czy możliwe jest szybkie uruchomienie aplikacji w  dowolnej wersji  @streser
  10. 10. @streser 5. Hypothesis of the impact of the change ­ czy wymagania są formułowane w postaci hipotez? ­ czy hipotezy pozwalają na zaplanowanie  eksperymentów, w których decyzje podejmowane są w  oparciu o dane statystyczne?
  11. 11. @streser 6. Testable Specification ­ czy istnieje aktualna specyfikacja? ­ czy jest ona regularnie testowana? ­ czy testy funkcjonlne (testy specyfikacji) są  zautomatyzowane?
  12. 12. @streser 7. Unit Tests ­ czy pokrycie kodu testami jednostkowymi umożliwia  bezpieczne wprowadzanie zmian bez konieczności  długiej fazy testów manualnych? ­ czy testy jednostkowe są pisane najpóźniej rownolegle  z kodem funkcjonalności?
  13. 13. @streser 8. Refactoring ­ czy refactoring jest codzienną praktyką? ­ czy za każdym razem gdy coś jest zmieniane w kodzie  wszyscy starają się poprawić jakość stosowanych  rozwiązań?
  14. 14. @streser 9. Continuous Integration ­ czy istnieje ciągła integracja w oparciu o jedną gałąź  w repozytorium (trunk)?  ­ czy wszyscy commitują/mergują do trunk'a  przynajmniej raz dziennie?  ­ czy każdy może modyfikować dowolny  moduł/komponent i to robi? ­ czy build jest często czerwony – czy testy spełniają  swoją rolę? 
  15. 15. @streser 10. STOP if tests fail ­ czy w przypadku, gdy testy w Continuous Integration  nie przejdą od razu podejmowane są akcje by naprawić  tą sytuację? ­ czy błędy z produkcji są naprawiane ASAP?
  16. 16. @streser 11. Automated Regression Testing ­ czy testy regresyjne są zautomatyzowane?  ­ czy sytuacje, w których nowe zmiany w  oprogramowaniu “psują” istniejącą funkcjonalność i  błąd ten trafia na produkcję zdarzają sie niezwykle  rzadko? 
  17. 17. @streser 12. Daily Deploy ­ czy przynajmniej raz dziennie (lub blisko)  na  produkcję trafia nowa wersja oprogramowania (lub  może trafić)? ­ ewentualnie czy na środowisku testowym testowana  jest  codziennie nowsza wersja oprogramowania?  
  18. 18. @streser 13. Release by switch ­ czy jest możlwe wydanie oprogramowania na  produkcję poprzez naciśnięcie jednego przycisku? ­ najlepiej czy jest możliwe wydanie nowej wersji  oprogramowania poprzez np. przekierowanie domeny  na inną wersję, lub podlinkowanie innego katalogu? ­ czy jest możliwość włączania i wyłączania dowolnych  ficzerów na produkcji? 
  19. 19. @streser 14. Validation of Hypothesis of Impact ­ czy wykonywane są testy A/B oraz testy wpływu  nowych zmian w oprogramowaniu na zachowanie  użytkowników? ­ czy zbierane są odpowiednie metryki pozwalające na  podejmowanie decyzji w oparciu o dane a nie o  przeczucie? ­ czy w razie, gdy okaże się, że zmiana nie przyniosła  oczekiwanych efektów, oprogramowanie jest sprzątane  I zmiany sa odwaracane?
  20. 20. @streser 15. Escaped Defect Root Cause Analysis ­ czy w przypadku, gdy defekt pojawi się na produkcji  za każdym razem wykonywana jest analiza przyczyn  zaistnienia tej sytuacji? ­ czy po zdefiniowaniu źródeł problemu jest ono  usuwane (nie jest stosowane obejście, lub jedynie  jednorazowe rozwiązanie)?
  21. 21. @streser Jaki wynik?
  22. 22. @streser Jak zacząć? 1. Definicja “jednostki pracy” 2. Value Stream Mapping (kamera na “jednostce  pracy”) 3. Poszczególne kroki w strumieniu wartości  przedstaw w postaci kolumn na tablicy 4. Definicja warunków przejścia do kolejnych kolumn 5. Ograniczenie pracy Work In Progress 6. Codzienne spotkania pomagające w synchronizacji  pracy 7. Pomiar czasu wykonywania “jednostek pracy” 8. Rgularne spotkania mające na celu usprawnianie  procesu poprzez planowanie kolejnych  eksperymentów(decyzje podejmowane w oparciu o  dane)
  23. 23. Stay LEAN! WE ARE HIRING!! Pragmatic Coders http://pragmaticcoders.com http://fb.com/pragmaticcoders @pragmaticcoders

×