Agenda

• Continuous integration

• Continuous delivery• Architekt – kto to jest?• Narzędzia pracy architekta• Zadania architekta

1

Continuous IntegrationCzyli sprawdź, zbuduj, opublikuj, nie wstając z łóżka

3

Ciągła integracja (CI) Co to jest właściwie?

▪ Praktyka integracji bieżących zmian w kodzie do głównego repozytorium

▪Możliwie dużo automatyzujemy

▪ Tak, można mieć z tego certyfikat (np. PCSCC-CI)

▪W teorii:

• Feature 1• Bug fix 1

Release 1

• Bug fix 2• Feature 2

Release 2• Bug fix 3• Bug fix 4

Release 3

4

5

Środowiska

▪ Local tam gdzie pracuje developer

▪Development/trunk development server, sandbox

▪ Integration używane przez CI, lub do testowania regresji

▪ Test/QA do testów funkcjonalnych, wydajności, QA

▪ Staging (pre-production) kopia środowiska produkcyjnego

▪ Production, live tam gdzie pracują klienci

6

7

Co potrzebujemy do CI

▪Repozytorium kodu▪ A w niej konwencje

▪ Automatyzację budowania kodu

▪ Automatyczne testy▪ Testy kodu▪ Testy builda

▪ Środowiska

▪ Automatyzacja publikowania

8

Przykładowe sytuacje kiedy CI ratuje nam D

▪ Trzeba poprawić release który ma klient a nie możemy mu dawać funkcji nad którymi pracujemy

▪ Trzeba się upewnić że nowe poprawki nic nie zepsuły w funkcjonalności do której dawno nie zaglądaliśmy

▪Mamy praktykanta

▪ Potrzebujemy instalki konkretnej wersji

▪ Potrzebujemy kopii środowiska produkcyjnego

▪ Jakie jest hasło do FTP klienta?

9

Visual Studio Online

▪ Integracja kodu, commitów, zadań, buildów (odpowiada na pytania: kiedy i czym coś poprawiliśmy / zepsuliśmy)

▪ Build agents – dla Windows, Android, iOS, Java…

▪ Automatyczne testy (unit tests, automated tests)

▪Diagnostyka i raportowanie

▪ Automatyczne publikowanie (również do Azure)

10

11

12

13

14

Jenkins: zrób to sam

▪Najpopularniejsze narzędzie

▪Warto znać, umieć skonfigurować

▪Działa w każdym środowisku (Java)

▪ Łatwy do opanowania interfejs www dla użytkowników

▪ Łatwy do rozszerzania

15

Continuous delivery

▪Dostarczanie oprogramowania w krótkich cyklach w celu zapewnienia odpowiedniej jakości

Architektura i projektowanieCzyli aplikacja ma warstwy (jak ogry)

17

18

Architekt

▪ Architekci oprogramowania

▪ Anders Hejlsberg, Linus Torvalds, Jeffrey Dean, John Carmack, Guido Von Rossum

▪ Kiedy potrzebujemy architekta?

▪ Kim jest ten tajemniczy człowiek?

19

20

Kiedy nie trzeba nic projektować lub wspomóc się pracą innych

▪Minimalizujemy wysiłek i korzystamy z dorobku innych

▪Wzorce kreacyjne (konstrukcyjne)▪ Np. builder, abstract factory, prototyping

▪Wzorce strukturalne▪ Np. adapter, dekorator, fasada

▪Wzorce czynnościowe (behawioralne)▪ Np. interpreter, iterator, observer, visitor

21

Daj sobie pomóc

22

Kiedy musimy coś zaprojektować

▪ Jakie mamy do tego narzędzia▪ Zdrowy rozsądek▪ Doświadczenie▪ UML

▪ Aby zachować odpowiednią równowagę…

23

24

UML

▪Diagramy struktury

▪Diagramy zachowań▪ Diagramy interakcji

▪Mnóstwo innych diagramów…

25

26

27

28

29

Zadania architekta

▪ Skąd bierzemy architekta?

▪Co należy do jego obowiązków?

▪Czy zawsze to jest konkretna osoba?

30

Warstwy i moduły

▪Multi-tiered apps – innych się już nie pisze!

▪Co to jest ta warstwa

▪Multitier architecture

▪Różne podejścia do podziału (top-down, bottom-up)

▪Co daje dobry podział na moduły i warstwy?

▪Co to jest właściwie ten moduł?

31

Architektura wielowarstwowa

▪Rozwinięcie podejścia klient-serwer

▪Najczęściej spotykane: 3 warstwy▪ Prezentacji▪ Aplikacji▪ Danych

▪ Transport: web services, sockets, middleware

▪Czasami definiowane (layers zamiast tiers)▪ Prezentacji▪ Aplikacji▪ Logiki▪ Dostępu do danych

▪ Aplikacja i logika często razem: MVP

32

Dziękuję

▪ Łukasz Roszak (lukasz.roszak@blstream.com)

▪Hubert Taler (hubert.taler@blstream.com)

▪Co poczytać?

http://www.norvig.com/design-patterns/

http://www.dofactory.com/net/design-patterns