
Charity Majors dolazi na Shift developerima pokazati put do raja (koji uključuje deployanje petkom!)
Ako vam je deploy sinonim za težak, dug i krhak proces, popravljanje bugova danima nakon... Ako vas jeza hvata od pomisli da deployate petkom, ovo predavanje je za vas.
Deploy petkom? Nema šanse, nitko si ne želi uništiti početak vikenda (ili cijeli vikend) popravljanjem bugova. Mantra je to koje se drži svaki developer zdravog razuma koji poštuje svoje i slobodno vrijeme svojih kolega. A možda više i ne?
Moderne tvrtke i moderni developeri usvojili su moderne DevOps prakse, automatizirali isporuku na produkciju i, u skladu s praksom kontinuirane integracije i kontinuirane isporuke (CI/CD) – deployaju stalno. Bez obzira koji dan ili doba dana bilo.
Rasprave o (ne)deployanju petkom uvijek su žučne, a memovi urnebesni.
Jedna od glasnijih zagovornica deployanja petkom, Charity Majors, softverska je inženjerka te suosnivačica i CTO startupa Honeycomb, koja je prije njegova osnivanja radila u Parseu i Facebooku, a na ovogodišnjoj konferenciji Infobip Shift developere će pokušati uvjeriti kako to uopće nije strašno.
Što je potrebno za zdrave isporuke od kojih developeri ne drhte?
Jedna od mojih omiljenih tema!, kaže Charity na molbu da pričamo baš o tom famoznom deployanju petkom. Odnosno, pojašnjava:
Zapravo, ne radi se samo o petku, nego o bilo kojem danu. Odnosno, o činjenici da isporuka softvera ne bi trebala biti nešto od čega developeri strahuju.
Je li isporuka sinonim za dug, težak i krhak proces od kojeg developeri zaziru? Ako nešto krene krivo, nekoliko inženjera potroši cijeli dan na čišćenje nereda? Možete li nakon isporuke biti sigurni da sve radi kako treba ili sljedećih par dana doznajete što sve ne radi od korisnika koji prijavljuju greške? U takvoj situaciji, ni ja se ne bih usudila deployati petkom!
Ali, to su sve samo znakovi bolesnog sustava. Možemo i trebamo raditi puno bolje!
Upravo o tome kako od bolesnih sustava isporuke doći do onih zdravih Charity će pričati na konferenciji. Put do toga je lakši nego što se misli:
Tehnički uopće nije zahtjevno, iako može biti socio-tehnički zahtjevno. Ali strah od deployanja je najveći izvor tehničkog duga u svakoj inženjerskoj organizaciji koju sam ikad vidjela. Svi koji drhte od same pomisli na deployanje petkom trebaju doći poslušati predavanje. Pokazat ću im roadmap do raja!
also: pic.twitter.com/UWvYgRyslP
— Charity Majors (@mipsytipsy) January 15, 2022
Charity ima još jedan razlog za zagovaranje deployanja bilo kad: odlično se uklapa u ono čime se bavi njezin startup. Honeycomb je alat za observability, sve popularniju nišu iz koje dolazi niz developerskih alata koji nude uvid u stanje koda i servisa, izvještaje koji olakšavaju pronalaženje i popravljanje grešaka. Poruka je jasna – uz alat koji pruža tako dobro poznavanje koda, lako je bilo kad samopouzdano deployati na produkciju.
“Nemoj deployati i pobjeći!
Charity objašnjava kako se deploya u Honeycombu:
Deployamo iz crona svakih 15 ili 30 minuta. Proces je potpuno automatiziran i svaki developer zna da kod ide u produkciju vrlo brzo nakon što napravi merge u main. Zato prije toga treba razmisliti je li kod spreman za to i ne raditi merge sve dok nije.
Pravilo, dakle, nije “ne deployaj petkom”, nego “nemoj deployati i pobjeći”. Bio to ponedjeljak u 5 popodne ili petak u 2 popodne, nemoj deployati ako nemaš vremena a) pratiti kod kako izlazi na produkciju, b) petljati po instrumentaciji i provjeravati jesu li promjene dobro prošle i c) pokrenuti povlačenje ili debugiranje ako nešto izgleda sumnjivo.
Vodimo se zdravim razumom i procjenom inženjera umjesto strogim pravilima. A zdravi razum i sposobnost procjene im svaki put postaju sve bolji!
Honeycomb je jedan od proizvoda na sve zasićenijem tržištu developerskih alata koji developerima, pojednostavljeno, olakšavaju posao (odnosno, kako je to slikovito rekao Bogdan Habić iz Tenderlyja – Kad developeri kopaju, mi dodajemo lopate.) A od kojih se sve više očekuje da nude odlično korisničko iskustvo i da su jednostavni i intuitivni kao bilo koji drugi digitalni alati (o odličnom developerskom iskustvu pri korištenju razvojnih alata pričao je i Paul Stack iz IaC alata Pulumi)
Charity komentira kako je dobro što je prošlo vrijeme pristupanja developerima kao da nisu ljudi:
To se počelo mijenjati. Donedavno smo imali developerske alate u kojima je vrlo lako sitnom greškom izazvati katastrofu, a vrlo teško napraviti ono što trebaš. Srećom, počeli smo pitati za pomoć prijatelje iz svijeta dizajna i korisničkog iskustva i kad su alati za developere u pitanju!
Developeri multipliciraju moć tehnologije. Dobri developerski alati pomažu nam da bolje koristimo svoje vrijeme i koncentraciju, iz buke prepoznamo prave signale i donosimo bolje odluke.
Inženjerska ili menadžerska karijera? Par godina jedno pa par godina drugo!
Kad ne zagovara deployanje petkom, Charity na društvenim mrežama i svom blogu često i vrlo angažirano piše o razvoju developerskih karijera. I na tu temu ima zanimljivo mišljenje: umjesto karijernih ljestvi, ona zagovara karijerno klatno. Odnosno, umjesto penjanja prema gore po izabranim ljestvama tehničke izvrsnosti ili upravljanja ljudima, preporučuje kombiniranje tih dvaju putova.
Jer, kako kaže, najbolji Engineering Manageri su oni kojima nije prošlo više od 5 godina otkad su programirali:
Svaki dobar tech lead bi trebao provesti jedno vrijeme kao voditelj, a svaki dobar voditelj je bio na mjestu onih koje vodi.
Na voditeljskoj poziciji naučiš puno toga, od motiviranja ljudi, do balansiranja poslovnih, tehničkih i timskih ciljeva, vođenja teških razgovora i davanja feedbacka, vođenja sastanaka, stvaranja najboljih timova, zapošljavanja… Sve to ti pomaže da razumiješ zašto neki projekti propadaju, zašto se donose neke tehničke odluke koje ti kao inženjeru nisu imale smisla, bolje razumiješ voditelje i odluke koje donose…To je skup vještina s kojima se možeš vratiti na inženjersku poziciju i itekako će ti biti od koristi da budeš još bolji inženjer!
Toga se drži i u svojoj karijeri – Charity je bila i Tech Lead i Engineering Manager i “samo” inženjerka, a sad je CTO.

Ima Engineering Managera koji su dobri, iako su zadnji put programirali prije 10 ili više godina, ali mislim da su najbolji Engineering Manageri oni koji se svakih par godina vrate u rovove programiranja. Nema boljeg načina za upoznavanje s novim alatima i praksama i razumijevanje kako je inženjerima od toga da si ti jedan od njih.
Osim toga, Charity smatra da je kombiniranje voditeljskog i inženjerskog posla svakih nekoliko godina najbolja odluka i što se tiče karijere:
Jednom kad postaneš senior kao inženjer, pred tobom je sigurno 30 godina karijere, zato je dobro okušati se u voditeljskom poslu, pa imati i tu mogućnost. S druge strane, voditelj koji je zadnji put programirao prije više od 5 godina, teško da će se moći opet zaposliti kao inženjer. Osim toga, mislim da je kombiniranje voditeljskog i inženjerskog posla i najzabavniji karijerni put!
Za još nekonvencionalnih karijernih savjeta i pristupa deployanju, ne propustite Charityno predavanje na konferenciji Infobip Shift…
Ne zaboravite, obećala je developerima pokazati put do raja!
Sukladno članku 94. Zakona o elektroničkim medijima, komentiranje članaka na Netokraciji dopušteno je samo korisnicima koji ostave svoje ime i prezime te mail adresu i prihvate pravila ponašanja.
Pravila ponašanja
Na Netokraciji za vas stvaramo kvalitetan, autorski potpisan sadržaj i zaista se veselimo vašim kvalitetnim, kontruktivnim komentarima. Poštujmo stoga jedni druge prilikom komentiranja, kao i Zakon, držeći se sljedećih pravila ponašanja:
Kako koristimo podatke koje ostavljate? Bacite oko na našu izjavu o privatnosti.
Sve ostale komentare ćemo s guštom spaliti, jer ne zaslužuju svoje mjesto na internetu.