Udvikling, hurtig og langsom

Tilpasning af udviklingspraksis til den decentrale verden

I 2001 var Philip, en af ​​vores udviklere, på et kundeside for at installere sin virksomheds software, da Oracle-databasen styrtede ned. Et par aflyste flyvninger senere havde han brugt yderligere 2 dage på at arbejde som DBA for at gendanne deres produktionsdatabase for dem. Han havde været på et enkelt supportopkald til Indien, England og Californien i 14 timer - non-stop. Først derefter kunne han faktisk starte installationen. Når han var færdig, ville han kun lære om brugen og de problemer, brugerne måtte have, hvis hans kunde ringede til ham for at fortælle ham.

Et par år senere, i 2010, var jeg klar til at frigive nogle nye funktioner til det sted, jeg arbejdede på. Jeg tændte et webstedsbanner for at indikere, at vi implementerede nye ændringer, og 5 minutter senere SSHed jeg ind på en server og kørte scripts / deploy.sh. 30 sekunder senere var de nye funktioner i gang, og vores brugere gav os deres tanker. De fik også en fejl ... En time senere lavede jeg den samme dans, og den blev løst.

Acceleration

Software engineering som en disciplin har ændret sig drastisk i løbet af de sidste 20 år. Den seneste udviklingstids æra er præget af kontinuerlig implementering, mest berømt brugt af virksomheder som Facebook og GitHub til at implementere ændringer på deres websteder snesevis af gange om dagen. Disse processer gør implementeringen et øjeblik og giver mulighed for at skubbe undergrupper af funktionalitet til forskellige brugergrupper. Slutresultatet: bugs, der opstår, er typisk begrænset til kun et par mennesker og har tendens til at være relativt små, fordi udvikling kan ske meget trinvist. De er lette at rette, kun få mennesker ser dem, og de bliver fanget tidligt.

En hyppig bivirkning af disse nemme fejlrettelser er, hvad du måske kalder en mere sjælden udviklingsproces. Da skyværktøjer blev mere almindelige, og kontinuerlig integration og implementering blev mere tilgængelig, er stive QA-testregimer blevet væsentligt mindre almindelige, især på mindre tidligere teams. I stedet for at overveje en funktion, der er klar til implementering, når den er fuldt undersøgt, har disse små hold skiftet til at acceptere fejl, fordi deres rettelser kan implementeres hurtigt. Dette har tilladt uafbrudt produktivitet, og når det er parret med korrekt prioritering af nye bugs, har det været en fantastisk måde at holde udviklings tempoet op og stadig have et produkt, der fungerer godt.

Meget af kontinuerlig udvikling findes på grund af stram, automatiseret kontrol over en organisations fulde stak af værktøjer og infrastruktur: et chatværktøj kan tale med en CI-server, der kan udløse en build og derefter distribuere til et par servere inden for organisationens infrastruktur. Indgående trafik gennemgår konfigurerede regler, der peger bestemte brugere på bestemte servere. Implementeret kode rapporterer telemetri tilbage, der kan bruges til hurtigt at få øje på en dårlig implementering og rulle den tilbage automatisk eller manuelt. Alle disse ting er ligetil, fordi disse organisationer kører deres egne systemer, kontrollerer den kode og konfiguration, der findes på hvert system, og modtager fuld telemetri fra alle fungerende maskiner eller VM'er i deres infrastruktur.

Decentralisering

Indtast decentrale netværk. Decentraliserede netværk er kendetegnet ved det modsatte af kontrol: en udviklingsorganisation, der implementerer et korrekt decentraliseret netværk, der højst kontrollerer en brøkdel af noderne i det samlede netværk. Kraften vender tilbage til folket, men det betyder, at infrastrukturen også er i folks hænder. Når alle de mennesker, der driver et netværks mange noder, er uafhængige aktører, er det meget sværere at koordinere en implementering. Et korrekt designet decentraliseret netværk respekterer privatlivets fred for dem, der kører knudepunkterne i netværket, så telemetri er opt-in, hvilket betyder, at meget af netværket muligvis slet ikke leverer telemetri til udviklerne.

Pludselig bemærker en fejl, der påvirker en delmængde af brugere, er meget sværere. Selvom en fejl bliver bemærket, er det kompliceret at få en løsning skubbet ud til alle. På en måde er vi vendt tilbage til den første historie i vores indlæg: at installere kode på en andens system og derefter lade den være uden nogen opdateringsfunktioner. Vi ved, hvad resultaterne af disse begrænsninger er: bugs, der tillader en dårlig skuespiller at stjæle millioner af dollars i ETH; bugs, der efterlader millioner af flere utilgængelige; forsøger at omgå kravene til decentralisering ved at centralisere kernetjenester. I sjældne tilfælde kan et stort samfund samle sig for at fortryde skaden, men af ​​både koordinering og ideologiske grunde kan dette være ret vanskeligt at få trukket ud.

Fortid, nutid, mød fremtid

Så hvordan skal decentrale udviklere håndtere denne justerede virkelighed? Kasserer vi alle de fordele, der opnås ved indførelsen af ​​kontinuerlig implementering, eller er der en mellemvej? Vi mener, at der er mange effektive metoder fra fortiden, der kan bringes til at bære vanskelighederne med decentraliseret udvikling. Kombineret med specifikke erfaringer fra kontinuerlig levering kan vi realisere mange af vores mål som udviklere selv i en decentral verden, samtidig med at vi opretholder den sikkerhed og sikkerhed, som brugere af decentrale systemer har brug for.

Interne testnetværk kan tillade en begrænset form for eksperimentering på nye iterationer. Disse testnetværk kan simulere knudefejl, almindelige transaktioner og mange andre aspekter af virkelige situationer for at give et højt sikkerhedsnet til netværksydelse og modstandsdygtighed. Desværre er det umuligt at simulere den virkelige verden fuldstændigt, så testnetværk kan kun føre os så langt - til sidst skal du sende.

Projekter, der er afhængige af kontinuerlig levering, kan sende et ufuldstændigt og ufuldstændigt minimums levedygtigt produkt og gentage sig meget hurtigt efter udgivelsen; et decentralt projekt skal derimod være mere opmærksom på, at dets oprindelige version poleres, især set ud fra et sikkerhedsperspektiv. Dette udelukker ikke et minimumsfunktionssæt - faktisk er MVP-tilgangen til at vælge nogle få funktioner at starte med uden tvivl vigtigere! Når forhåndsomkostningerne er højere, er lancering med mindre for at få mulighed for at teste kernefilosofier i naturen endnu mere afgørende.

Tidligt er et entusiastisk samfund også en fantastisk måde at få mange af fordelene ved en central infrastruktur: glade nodeoperatører vil være ivrige efter at prøve nye versioner og aktivt give feedback. Efterhånden som samfundet vokser, fortsætter større engagement med at gøre det lettere at implementere det. Community management bliver således endnu vigtigere, da et community, som stoler på, at udviklerne vil være mere villige til at arbejde sammen med dem for at implementere nye ændringer og reducere deltaet mellem selvdrevet og community-driven infrastruktur. Stærk udviklingspraksis og kode af høj kvalitet skaber også tillid fra samfundet, hvilket igen fører til reduceret risiko og mere vilje til at implementere nye ændringer.

Der er mange flere måder at låne og tilpasse eksisterende lektioner, for nylig og ikke for nylig, i en decentral verden. Vi håber at fortsætte med at dele vores tanker om disse i de kommende uger, når vi diskuterer, hvordan vi nærmer os de første udgivelser af Keep Network.

Tak til James Prestwich og Brayton Williams for at have gennemgået tidlige udkast til denne historie.

Learn More

For more information about the Keep Network:

• Join us on Reddit.
• Check out our whitepaper.
• Read our business primer.
• Subscribe for email updates.
• Follow us on Twitter.
• Join our Slack.
• Join our Telegram.