Razvoj, brz i spor

Prilagođavanje razvojnih praksi decentraliziranom svijetu

2001 godine, Philip, jedan od naših programera, bio je na web mjestu korisnika kako bi instalirao softver svoje tvrtke kada se Oracle baza podataka srušila. Nekoliko otkazanih letova kasnije, proveo je dodatna dva dana radeći kao DBA da bi im vratio bazu podataka. Već je 14 sati neprekidno uputio jedan poziv za podršku Indiji, Engleskoj i Kaliforniji. Tek nakon toga mogao je zapravo započeti instalaciju. Kad završi, saznat će samo o njegovoj upotrebi i svim problemima koje bi korisnici mogli imati ako bi ga kupac nazvao da ga obavijesti.

Nekoliko godina kasnije, 2010. godine, bio sam spreman objaviti neke nove značajke na web mjestu na kojem sam radio. Uključio sam natpis web stranice kako bih naznačio da uvodimo nove promjene i, pet minuta kasnije, SSHed sam u poslužitelj i pokrenuo skripte / deploy.sh. 30 sekundi kasnije, nove su značajke pokrenute i korisnici su nam iznosili svoja razmišljanja. Uhvatili su i bubu ... Sat vremena kasnije i ja sam izvela isti ples i to je bilo popravljeno.

Ubrzanje

Programski inženjering kao disciplina drastično se promijenio tijekom posljednjih 20 godina. Najnovije doba razvoja obilježava kontinuirano postavljanje, a najpoznatije ga koriste tvrtke poput Facebooka i GitHub-a kako bi desetine puta dnevno primijenile promjene na svojim web lokacijama. Ovi procesi čine implementaciju brzom i omogućuju guranje podskupina funkcionalnosti različitim korisničkim skupinama. Krajnji rezultat: bugovi koji se pojavljuju obično su ograničeni na samo nekoliko ljudi i imaju tendenciju da budu relativno mali jer se razvoj može dogoditi vrlo postepeno. Lako ih je popraviti, malo ih ljudi vidi i rano ih uhvate.

Jedna od čestih nuspojava ovih jednostavnih ispravki programskih pogrešaka je ono što biste mogli nazvati višestrukim procesom razvoja. Kako su alati u oblaku postajali uobičajeniji, a kontinuirana integracija i implementacija postajali pristupačniji, kruti režimi QA testiranja postali su znatno rjeđi, posebno kod manjih timova u ranijoj fazi. Umjesto da razmatraju značajku spremnu za implementaciju kad je u potpunosti provjerena, ovi mali timovi prešli su na prihvaćanje programskih pogrešaka jer se njihovi popravci mogu brzo primijeniti. To je omogućilo nesmetanu produktivnost, a u kombinaciji s pravilnim određivanjem prioriteta za nove bugove, izvrstan je način da se ubrza razvoj i još uvijek ima proizvod koji dobro funkcionira.

Mnogo kontinuiranog razvoja postoji zbog uske, automatizirane kontrole nad čitavim nizom alata i infrastrukture organizacije: alat za chat može razgovarati s CI poslužiteljem koji može pokrenuti izgradnju i zatim se rasporediti na nekoliko poslužitelja unutar infrastrukture organizacije. Dolazni promet prolazi kroz konfigurirana pravila koja usmjeravaju određene korisnike na određene poslužitelje. Postavljeni kod izvještava o telemetriji koja se može koristiti za brzo uočavanje lošeg rasporeda i njegovo vraćanje natrag, automatski ili ručno. Sve su ove stvari jednostavne jer ove organizacije pokreću vlastite sustave, kontroliraju kod i konfiguraciju koji postoje u svakom sustavu i primaju potpunu telemetriju sa svih funkcionalnih strojeva ili VM-ova u svojoj infrastrukturi.

Decentralizacija

Uđite u decentralizirane mreže. Decentralizirane mreže karakterizira suprotno od upravljanja: razvojna organizacija koja raspoređuje pravilno decentraliziranu mrežu kontrolira najviše dio čvorova u ukupnoj mreži. Snaga se vraća ljudima, ali to znači da je i infrastruktura u rukama ljudi. Kad su svi ljudi koji vode brojne mrežne čvorove neovisni akteri, mnogo je teže koordinirati implementaciju. Pravilno dizajnirana decentralizirana mreža poštuje privatnost onih koji upravljaju čvorovima u mreži, pa je telemetrija uključena, što znači da velik dio mreže možda uopće ne dostavlja telemetriju programerima.

Odjednom je puno teže primijetiti grešku koja utječe na podskup korisnika. Čak i ako se primijeti bug, komplicirano je izbacivanje ispravka svima. U određenom smislu, vratili smo se prvoj priči u našem postu: instaliranju koda na tuđi sustav, a zatim ga ostavljamo bez mogućnosti daljinskog ažuriranja. Znamo kakvi su rezultati ovih ograničenja: greške koje dopuštaju lošem glumcu da ukrade milijune dolara u ETH-u; bugovi zbog kojih su milijuni nedostupni; pokušava zaobići zahtjeve decentralizacije centraliziranjem osnovnih usluga. U rijetkim se slučajevima velika zajednica može okupiti kako bi popravila štetu, ali iz koordinacije i iz ideoloških razloga to može biti prilično teško izvesti.

Prošlost, sadašnjost, susret budućnosti

Pa kako bi se decentralizirani programeri trebali nositi s ovom prilagođenom stvarnošću? Odbacujemo li sve prednosti stečene uvođenjem kontinuiranog raspoređivanja ili postoji srednji put? Vjerujemo da postoje mnoge učinkovite prakse iz prošlosti koje se mogu prilagoditi poteškoćama decentraliziranog razvoja. U kombinaciji s određenim lekcijama iz kontinuirane isporuke, možemo ostvariti mnoge svoje ciljeve kao programeri čak i u decentraliziranom svijetu, a istovremeno zadržati sigurnost i sigurnost potrebnu korisnicima decentraliziranih sustava.

Interne testne mreže mogu dopustiti ograničeni oblik eksperimentiranja na novim iteracijama. Te testne mreže mogu simulirati kvarove na čvorovima, uobičajene transakcije i mnoge druge aspekte stvarnih situacija kako bi osigurale sigurnosnu mrežu na visokoj razini za performanse i otpornost mreže. Nažalost, nemoguće je u potpunosti simulirati stvarni svijet, tako da nas ispitne mreže mogu nositi samo do sada - na kraju morate isporučiti.

Projekti koji se oslanjaju na kontinuiranu isporuku mogu isporučiti nesavršeni i nepotpuni minimum održivog proizvoda i vrlo brzo ga ponoviti nakon objavljivanja; decentralizirani projekt, s druge strane, mora voditi više računa da njegova početna verzija bude uglađena, posebno iz sigurnosne perspektive. To ne isključuje minimalni skup značajki - zapravo je MVP pristup odabiru nekoliko značajki za pokretanje vjerojatno važniji! Kad su unaprijed troškovi veći, pokretanje s manje da biste dobili priliku testirati temeljne filozofije u divljini još je presudnije.

Rano je entuzijastična zajednica također sjajan način da se iskoriste mnoge prednosti centralizirane infrastrukture: uzbuđeni operateri čvorova željni će isprobati nove verzije i aktivno pružiti povratne informacije. Kako zajednica raste, sve veći angažman i dalje znači lakšu implementaciju. Upravljanje zajednicom stoga postaje još važnije jer će zajednica koja vjeruje programerima biti spremnija surađivati ​​s njima na uvođenju novih promjena i smanjenju delte između infrastrukture kojom upravljaju korisnici i zajednice. Snažne razvojne prakse i visokokvalitetni kod također rađaju povjerenje zajednice, što zauzvrat dovodi do smanjenog rizika i veće spremnosti za uvođenje novih promjena.

Postoji mnogo više načina za posuđivanje i dorađivanje postojećih lekcija, nedavnih i ne tako nedavnih, u decentraliziranom svijetu. Nadamo se da ćemo i tijekom sljedećih tjedana nastaviti dijeliti svoja razmišljanja o tome dok razgovaramo o tome kako se približavamo prvim izdanjima Keep Network.

Hvala Jamesu Prestwichu i Braytonu Williamsu na pregledu ranih nacrta ove priče.

Saznajte više

Za više informacija o Keep Network:

• Pridružite nam se na Redditu.
• Pogledajte našu tehničku knjigu.
• Pročitajte naš poslovni priručnik.
• Pretplatite se na ažuriranja putem e-pošte.
• Pratite nas na Twitteru.
• Pridružite se našem Slacku.
• Pridružite se našem Telegramu

Zahvaljujući Jacku Knutsonu, Hope Cowan i Lauri Wallendal.