Pridonošenje open source zajednici može pružiti developerima veliki osjećaj ispunjena znajući da njihov uradak može utjecati na rad tisuće i tisuće ostalih udaljenih kolega koji imaju slične afinitete.
Evo priča iz tog područja koje su s nama podijelili iz Trikodera…
Govorim vam iz iskustva kada kažem da jednom kada smo vidjeli kakav pozitivni udar naše kreacije imaju na zajednicu, cijela stvar se naprosto pretvorila u malu ovisnost. Jednostavno se nismo mogli zaustaviti sa novo dobivenom željom da nastavimo ulagati u open source. Napokon smo bili uzeli priliku da uložimo natrag u open source, pogotovo zbog činjenice da se velika većina naših rješenja upravo i temelji na open source komponentama bez kojih bi izgubili na fleksibilnosti i lakoći njihovog razvoja.
Ta mala ovisnost je proizašla iz našeg prvog uspjeha u open sourceu gdje smo izdali razvojni paket koji u ovom trenutku broji preko 25.000 preuzimanja na GitHubu i preko 17 aktivnih contributora. O cijelom putovanju moći ćete čuti na drugom danu .debug konferencije u 15:30 sati, a do tada ću vas ostaviti sa par zanimljivih situacija kroz koje smo prošli baveći se open sourceom – govori Petar Obradović, arhitekt Njuškalo platforme u Trikoderu.
Preko noći do slave
Jedan od izazova izdavanja open source rješenja van u javnost je kako se istaknuti u moru ostalih rješenja koja već postoje u ekosistemu u kojem operirate. Sve se svodi na to da vaše rješenje treba zadovoljiti developerov “svrbež” tj. učiniti njihov život barem malo lakšim. Jednom kada vaše rješenje dođe na dobar glas u zajednici, njezina popularnost može eksplodirati viralno.
Ali kao i uvijek, inicijalno probijanje može se pokazati kao dosta veliki izazov ako govorimo o zrelom ekosistemu koji vrvi sa već provjerenim rješenjima. Developeri vole stabilnost i sigurnost. Moje dosadašnje iskustvo je pokazalo da prezentiranje vašeg rješenja na lokalnim okupljanjima (meetupovima), objavljivanje na društvenim mrežama i raznim drugim forumima može imati vrlo pozitivan efekt, uz uvjet da prije svega ostvarite neki bazni kontakt s uključenim ljudima kako isti ne bi doživljavali vaše objave kao spam (nitko ne voli spam).
Sve navedeno gore bismo mogli svrstati pod standardne komunikacijske kanale, no postoje i druge metode koje mogu pružiti inicijalnu eksploziju koja će vas staviti na radar ostalih developera. U našem slučaju u Trikoderu, bilo je dovoljno napraviti pull request na GitHub repozitoriju biblioteke na kojem se naš razvojni paket temelji da ga izlistamo u dokumentaciji kao jedan od podržanih načina integracije. Postojala je prvobitna nesigurnost oko toga da li nam se uopće isplati pokušati otvoriti pull request, jer naime, tko će na megapopularnom repozitoriju sa preko pet tisuća zvjezdica htjeti zamarati sa nekim tu novim likovima.
“Postoji preko 20 otvorenih pull requestova već neko vrijeme i nikako da se integriraju u repozitorij. Zašto bi oni doživjeli naš?” – mislimo si. Nakon podosta promišljanja i gnjavaže ostalih kolega zaključili smo da nemamo ništa za izgubiti. Imali smo paket kojim se ponosimo i bili smo spremni podijeliti ga s ostatkom zajednice. Ako se dogodi da naš zahtjev da izlistamo paket u dokumentaciji ostane nezapažen, nije da ćemo biti u lošijoj poziciji nego prije.
Sretno vam mogu otkriti da je pull request koji smo dali na repozitorij bio promptno prihvaćen te nam je lansirao aktivnost paketa sa par preuzimanja tjedno na preko 100 svakih 24 sata! U tom trenutku smo znali da prava avantura tek počinje.
“Zašto nismo još ovo automatizirali?”
Razvojni paket je objavljen, ljudi su ga doživjeli, aktivnost mu raste… i što sada? Više se ne radi o uratku kojeg koristi 10-nešto developera interno u firmi. Novi ljudi dolaze na tjednoj bazi koji su voljni pridonijeti paketu kako bi povećali njegovu kvalitetu. Kako osigurati da uz cijeli priljev nove aktivnosti se sve ne raspadne?
Ključni pojam u cijeloj priči je continuous integration. To je proces pri kojem svaka izmjena u repozitoriju (neovisno bio to kod ili dokumentacija) prolazi kroz predefinirani pipeline koji provodi niz provjera (radnji) koje osiguravaju da izmjene koje developer pokušava unijeti u repozitorij ne sruše projekt za ostale korisnike. Primjer radnji bi bio: vrćenje testova koji potvrđuju da kod radi po očekivanim ponašanjima, prolazak kroz kod pomoću linter alata da potvrdimo da stil pisanja koda zadovoljava uniformne standarde, provjera formata Git poruka, itd…
Uz kvalitetno postavljen continuous integration pipeline, developeri koji pridonose na repozitorij mogu dobiti trenutan feedback da li će se njihov doprinos kodu uspješno integrirati u cijelu priču ili ne. Što više procesa dodate u sam pipeline, time ćete si osloboditi više vremena baviti se stvarima koje računalo ne može odraditi samostalno (još), a i imat ćete lakši san znajući da kolega Janko nije strgao paket za ostalu ekipu koja se oslanja na njega (Janko nikada nije bio fan pisanja testova).
Sam proces migracije našeg CI pipelinea na Travis CI (što je preferirani servis u svijetu GitHuba) sa GitLab CI se čak i nije pokazao kao izuzetno veliki problem. Sve se svodi na definiranju konfiguracijske datoteke koja daje instrukcije testnoj mašini što treba točno napraviti da bi osigurali da naše softversko rješenje funkcionira pravilno. Ako išta pođe po zlu, testna mašina prekida izvršavanje te daje feedback developeru o tome što treba popraviti.
Postoji masa procesa koji se daju automatizirati koji mogu olakšati naš svakodnevni posao…
Zanima vas koji bi to mogli biti? Dođite na predavanje Berislava Balogovića koji će vam ispričati kako smo u Trikoderu došli od frustracije do automatizacije uz GitLab na prvom danu .debug konferencije u 12:35 sati.
“Ma to je samo jedna izmjena linije u kodu”
Jedna od neočekivanih posljedica kada vam vaš open source projekt dobije na popularnosti je novostvoreni osjećaj odgovornosti prema korisnicima. Nekoč male greške koje se mogu potkrasti svima nama s vremena na vrijeme (ipak smo ljudi) dođu puno više do izražaja kada veliki broj developera ovisi o vašem projektu.
Incident koji nam se dogodio u ranim povojima potvrđuje tvrdnju iznad. Bio je to još jedan od sunčanih dana kolovoza te smo upravo napravili drugi veliki release našeg razvojnog paketa. Sve je izgledalo super i lista izmjena nije razočarala. Kliknuli smo “Publish release” na GitHubu i krenuli sa slavljem. Nije prošlo ni sat vremena kako se moj developerski OCD aktivirao. Postojala je jedna klasa u paketu koja me toliko pekla za oči da sam je u tom trenutku trebao odmah refaktorirati, pod bilo koju cijenu.
Rekao sam si kako ću izmjenu napraviti na “master” grani paketa kako ne bih utjecao na ostale korisnike. Pošto se radilo o izmjenama svega par linija koda, odlučio sam i zaobići naš regularni proces integracije. Tko će čekati 20 minuta da se propagira tako jednostavna izmjena? Ovaj tijek misli je u retrospektivi bio toliko pogrešan da to ne mogu opisati.
Sljedeće što se dogodilo nakon što sam poslao promjene na “master” granu, u roku od par minuta su počele dostizati prijave na repozitorij sa prijavama developera da su im aplikacije prestale raditi. Ispostavilo se da promjene koje sam uveo nisu pokrile određene rubne slučajeve, jer tko bi rekao, ljudi vole konfigurirati svoje aplikacije na razne kreativne načine koje nisam predvidio u limitiranom vremenu koje sam uložio u same izmjene. Ubrzo nakon par prijava sam odlučio poništiti promjenu i ispričao se radi nastanka poteškoća u radu. Ispada da neki developeri vole živjeti opasno i targetiraju “bleeding edge” varijante vašeg paketa (no to definitivno ne opravdava da bi im se trebala trgati okolina svakom mogućom prilikom).
Nemojte slijediti ovaj primjer te odrađujte izmjene na vašem open source projektu promišljeno, fokusirano te nemojte zaobilaziti procese koje ste postavili sami sebi i ostalim kolegama, bez obzira čine li se oni kao overkill u danom trenutku. Postavljeni su tu iz razloga. Budući “ti” će vam biti zahvalan.
Ako ste zainteresirani čuti cijelu priču kako smo od internog rješenja razvili uspješan punokrvni open source projekt, dođite na drugi dan .debug konferencije. Predavanje Petra Obradovića počinje u 15:30 sati.
O kojem se projektu radi? Pogledajte više na: https://github.com/trikoder/oauth2-bundle/
Više o svemu saznajte na .debug konferenciji 12. i 13. prosinca 2019.
