Każdy programista w zespole może w ten sposób bez problemu wykonać w ciągu miesiąca min. 20-50 deploymentów na produkcję.
Nasz sposób pracy daje bardzo dużo satysfakcji z tego co robimy ponieważ efekty naszych starań są dostarczane niemal natychmiast. Masz zastrzeżenia? Zapraszamy do pytań na pierwszej rozmowie i komentowania nas na LinkedIn!
Nie pracujemy na branchach, robimy Trunk-Based Development. Wszystkie nasze commity wrzucamy na master
i z reguły każdy commit kończy się deploymentem na produkcję.
Każdy programista w zespole może w ten sposób bez problemu wykonać w ciągu miesiąca min. 20-50 deploymentów na produkcję.
Trunk-Based to to samo co Continuous Integration, Continuous Deployment, Continuous Delivery. Te nazwy są jednak mylące ponieważ najczęściej używa się ich w stosunku do narzędzi CI/CD - a te z kolei nie wymagają przecież pracy bez branchy.
Praca przebiega płynnie i bezstresowo, ponieważ nie występują merge conflicts, a jeśli nawet występują to ich rozwiązanie zajmuje sekundy. Dzień kończy się z spokojną głową gotową na inne aktywności.
Taki sposób pracy daje też o wiele więcej satysfakcji z tego co robimy ponieważ efekty naszych starań są dostarczone do użytkowników czy biznesu niemal natychmiast.
Całkowicie normalną i bezpieczną sytuacją jest wykonywanie deploymentów w piątki, a nawet jest to sytuacja pożądana(!).
Zobacz nagranie PHPers Summit (największa polska konferencja PHP):
(Prezentacja language-agnostic)
Tworząc kod rzeczywiście zaczynamy pracę od napisania failującego testu (red). Następnie implementujemy funkcjonalność, którą ten test “zazielenia” (green). Na samym końcu ma miejsce refactoring.
W przeważającej większości przypadków stosujemy klasyczne podejście do testów (tzw. szkoła Detroit). Jeśli chodzi o podejście mockistyczne (szkoła Londyńska) to stosujemy je bardzo rzadko, tam gdzie to podejście ma faktycznie sens.
Testy piszemy w standardzie jednej linijki na każdą z części arrange
, act
oraz assert
.
Aby doprowadzić kod do tego standardu często wymaga to refactoringu nie tylko testów ale też kodu produkcyjnego. Natomiast niemal w każdym przypadku gwarantuje to dobrą jakość kodu: czytelność, dobrą organizację, odpowiednie abstrakcje itd.
Nieintuicyjny ale skuteczny sposób na brak bugów.
Praktykujemy zasadę Fail Fast tzn. częste i agresywne stosowanie exceptionów i asercji stopujących execution procesu.
Fail Fast dosłownie dziesiątkuje liczbę bugów w naszym kodzie do liczb bliskich 0. Z tego powodu jest to jeden z fundamentów naszego podejścia do kodu.
Fail Fast prezentowaliśmy podczas kilku meetupów i konferencji. Zobacz nagranie z Gdańska tutaj lub poniżej:
(Prezentacja language-agnostic)
Poszukujemy osób, które potrafią wykorzystać dobre praktyki tworzenia kodu lub są chętne i otwarte aby się ich nauczyć.
Potrafimy przekonać naszych klientów w inwestycje w dług techniczny. Sprawny monitoring, skrypty deploymentowe, CD/CD pipeline, zaczynanie od napisania testu są u nas podstawą i codziennością.
Stosujemy również m.in. Domain-Driven Design, Infrastructure as Code, feature toggles, Extreme Programming, DevOps/Theory of Constraints, Clean Code, SOLID, KISS, YAGNI, a także szeroko pojętą automatyzację.
Pracujemy na bardzo małych iteracjach. Dzielimy duże stories na wiele małych. W środowisku gdzie pracuje się bez branchy i bardzo często deploy'uje kod na produkcję Scrum nie wnosi po prostu żadnej wartości.
W praktyce stosujemy proste kanban boardy i agresywnie limitujemy przy tym Work-In-Progress. Nasi programiści w danej chwili mają “otwarte” tylko i wyłącznie jedno story.
Nasze boardy posiadają 5 kolumn: MAYBE
, TO DO
, IN PROGRESS
, DONE
, ACCEPTED
z czego pierwsza i ostatnia kolumna to tylko szybkie "bramki" dla managera i klienta.
Code review wykonujemy “na żywo” np. podczas połączenia wideo prezentujemy ekran i rozmawiamy o kodzie. Dzięki temu oszczędzamy czas i energię - unikamy długich dyskusji na GitHub czy Slack. Ponadto, w związku z zasadą limitowania WIP, code review ma priorytet nad nowymi zadaniami.
W ciągu 1-2h od skończenia story Twój kod jest na produkcji, masz zrobione code review, story jest zaakceptowane przez "biznes", a Ty zabierasz się za kolejne zadanie.
Nie zatrudniamy testerów/QA. Piszemy również testy angażujące UI (aka e2e, acceptance) w PlayWright (narzędzie podobne do Selenium).
To właśnie w/w konkretne narzędzia i praktyki stosowane na co dzień, sprawiają, że możemy uważać się za organizację, która swoją pracę dostarcza w duchu takich idei jak Agile, DevOps, Continuous Delivery czy Extreme Programming.
Dzięki tym praktykom skutecznie skracamy tzw. feedback loop oraz minimalizujemy cycle time projektów.
Zobacz wywiad z Konradem Otrębskim na kanale Nerd Management:
Newsletter
Praktyczna wiedza o budowie software szybko i bez bugów. Niuanse, które pomija reszta branży, a które będą stanowić przewagę konkurencyjną Twojego biznesu.