O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Few Questions about Continuous Delivery

1.020 visualizações

Publicada em

15 questions about Continous Delivery and Lean Software Development which will help you measure how god is your process.

Publicada em: Software
  • Seja o primeiro a comentar

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

×