DevTalk#45 – O Continuous Delivery z Łukaszem Szydło

6

Łukasz SzydłoDziś, w 45. odcinku, temat bardzo potrzebny. Temat, dzięki któremu praca programisty może stać się… przyjemniejsza. I o wiele mniej stresująca.

Moim i Waszym gościem jest Łukasz Szydło: programista, architekt, konsultant, trener. Możecie go spotkać na wielu konferencjach, bo aktywnie dzieli się na nich swoją wiedzą. I dobrze, bo ma czym się dzielić! Na Twitterze: @lszydlo.

Rozmawiamy o Continuous Delivery. Continuous * (gwiazdka) to kwestie bardzo popularnie w ostatnich latach. Z tej rozmowy dowiecie się, o co tak naprawdę chodzi. I jak zapukać do bram programistycznego raju. A także, co mi samemu bardzo dało do myślenia: czy na pewno potrzebujemy branchy w naszej kontroli wersji?

Zarówno Łukasz, jak i ja, prowadzimy szkolenia z tego zakresu. Link do szkolenia Łukasza tutaj, a do mojego: tutaj.

Brzmi ciekawie? Mam nadzieję. PLAY!


Montaż odcinka: Krzysztof Śmigiel.
Ważne adresy:


Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

6 Comments

  1. Kacper Kozak on

    Cześć, bardzo fajny devtalk!
    Ale tylko jedno pytanie: jak wygląda code review przy CD gdy nie mamy branchy?
    Czy przy takim podejściu pozostaje nam tylko i wyłącznie programowanie w parach?

    • Łukasz Szydło on

      Programowanie w parach to jedno rozwiązanie. Drugie nazywam “pre-push review”. Polega to po prostu na poproszeniu członka zespołu o szybkie review zanim zrobisz push-a. Zastępujemy w ten sposób jedno długie review kilkoma krótszymi. Można też robić blokowane feature switche. Na przykład do puki ktoś z zespołu nie oznaczy feature jako sprawdzony nie da się go włącz na systemie produkcyjnym lub testowym.

  2. Sam myślałem o feature switchach. Swoją droga byłem chyba na jakiejś prezentacji w tym temacie. Było kontrowersyjnie, zwłaszcza, jak padł tekst – branche są wolne :)
    Generalnie pewnie niedługo spróbuję czegoś takiego.

  3. Po raz pierwszy muszę przyznać że to gość miał jednak więcej racji, feature flags/toggles powoli wyrastają na ważną rzecz w zespołach które muszą dostarczać często.

    Można też o tym poczytać w e-booku “From Agile to DevOps at Microsoft Developer Division”, strona 6 rozdział “Code velocity and branching”.

Newsletter: devstyle weekly!
Dołącz do 1000 programistów!
  Zero spamu. Tylko ciekawe treści.
Dzięki za zaufanie!
Do przeczytania w najbliższy piątek!
Niech DEV będzie z Tobą!