Dziś, 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?
Brzmi ciekawie? Mam nadzieję. PLAY!
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
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?
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.
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.
Artykuł od M. Fowlera: http://martinfowler.com/articles/feature-toggles.html
Ostatnie znalezisko nieco w temacie: https://github.com/Stuie/papercut – jesli kiedys zdarzylo Ci sie skomitowac niewykomentowany kod `lekko` zmieniajacy funkcjonalnosc, badz aktywowac nie ten ficzer brancz…
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”.