Hvordan og hvorfor lærer vi ikke-ingeniører at bruge GitHub på Thread

På tråden er en af ​​vores grundlæggende overbevisninger, at teknologi giver mulighed for store ændringer. Dette er vigtigt for vores produkt, men det er også vigtigt for, hvordan vi arbejder internt.

På grund af denne måde at arbejde på, prøver vi at repræsentere alt inden for data - produkter, målinger, stilarter, leverandører, placeringer i vores lager, supportbilletopløsninger og mange flere ting, som du aldrig engang ville tænke på.

Alle disse datamodeller leveres med omkostningerne ved at have brug for en måde for dem i virksomheden, der bruger dem til at vedligeholde dataene. Dette betyder at oprette redigeringsgrænseflader med validering, databasedesign og front-end arbejde. Ofte har vi bare ikke tid til at gøre dette - nye funktioner har højere prioritet, og desuden kan en ingeniør bare opdatere et par datafiler, når det er nødvendigt, ikke?

Selvom dette er en meget hurtigere løsning på kort sigt, er en ingeniør nødt til at skifte kontekst fra deres arbejde, se frigivelsen gå ud og sørge for, at intet går galt - at alt skader produktiviteten. Måske mere vigtigt er det dog, at den person, der har behov for de opdaterede data nu, ikke længere har ejerskab af hele processen og er afhængig af en andens tidsplan.

I sidste ende kan denne proces være nyttig til hurtigt at få en funktion ud af døren, men får alt for meget friktion til at arbejde på lang sigt.

En bedre løsning

Jeg kan huske, da GitHub først lancerede deres webeditor - Jeg var ikke imponeret. Hvorfor skulle nogen redigere kode i en webbrowser? Hvorfor skulle jeg bruge en editor, der kun kunne ændre en fil pr. Engagement? Mange år senere har jeg indset, at jeg ikke er målmarkedet for redaktøren.

Hos Thread lærer vi nu regelmæssigt dem uden for ingeniørteamet, hvordan man kan bidrage til vores codebase via GitHub-webgrænsefladen, så de har kontrol over opdatering af data, de har brug for for at fungere effektivt.

Vi har nu haft flere bidragydere til vores vigtigste codebase, der er i ikke-tekniske roller, end alle ingeniører og entreprenører, der har bidraget gennem årene.

Har det fungeret?

Som ingeniør i produktteamet er jeg i stand til at fokusere min indsats på at opbygge funktioner, der vil være til gavn for vores kunder og flytte målinger, snarere end på at opbygge flere CRUD-grænseflader. Jeg er også i stand til at sende A / B-test hurtigere, da vi ofte kan springe over det interne værktøj til testversionen til fordel for redigering af data gennem datafiler til at begynde med. Når vi kommer til leveringsfasen af ​​et projekt, kan vi derefter placere tiden i redigeringsgrænsefladerne, da vi ikke kun har en idé om værdien af ​​funktionen, men også har en bedre idé om, hvordan vores interne brugere gerne vil have grænseflader til arbejde.

Det er heller ikke begrænset til datafiler; mange sider på thread.com er hovedsagelig statisk HTML, sider som vores ofte stillede spørgsmål om levering, returneringspolitik eller vilkår og betingelser. Ved at lære at bruge GitHub, kan vores operationsteam holde disse opdaterede uden at bede om hjælp. Vores talentteam er også i stand til at redigere vores jobsite og reagerer dagligt på almindelige spørgsmål, der dukker op, når vi taler med kandidater.

Alt dette betyder, at vores teammedlemmer uden for ingeniørteamet er i stand til at have meget mere ejerskab over deres arbejde, og har mindre friktion til at foretage de ændringer, deres erfaring fortæller dem, er nødvendige.

Hvordan gør vi det?

Den første ting, vi gør, er at køre GitHub-tutorials hver gang og igen, når vi har et par nye startere til at undervise. Vi dækker det grundlæggende om, hvad et depot er, sammenligner det med dokumentrevisionshistorier på Google Dokumenter, hvad det betyder at udgive en fil, og hvad en filial er. Vi taler kun om disse på højt niveau måder, da vi overhovedet ikke dækker kommandolinjegrænsefladen i vores nuværende tutorialformat.

Herefter gennemgår vi, hvordan vi redigerer en fil på GitHub-webgrænsefladen, hvordan man skriver en engagementsmeddelelse, hvad en pull-anmodning er, og hvad build-statusrapportering fra Jenkins betyder.

Til sidst beder vi ikke-tekniske bidragydere om at vælge en ingeniør, der er tilgængelig på Slack, for at trykke på fletningsknappen, når bygningen er grøn.

Problemer, vi er stødt på

Alt i alt føler vi, at dette er en enorm gevinst for holdet som helhed, og vi planlægger at fortsætte træningen og opmuntre flere bidragydere, når vi vokser, men vi har ændret vores proces lidt efterhånden som dette har udviklet sig.

For det første har vi brugt GitHub-roller og låste grene for at forhindre utilsigtede forpligtelser til at mestre. For en person, der ikke er så fortrolig med versionskontrol og filialer, er GitHub-webgrænsefladen ikke særlig klar over, hvornår en engagement foregår til mastergrenen eller en ny filial. Hos Thread implementeres vores masterfilial kontinuerligt uden manuel indgriben krævet, hvilket resulterede i flere forpligtelser, der gik ud, der brød stedet og forårsagede driftsstop.

Hvad angår alle problemer med nedetid, løb vi et skyldløst 5 Whys og indså, at mens vi i bagspejlet kunne have fanget disse problemer med enhedstest, der blev kørt før installationen, ville vi sandsynligvis ikke fange alt, og så at indføre beskyttede grene for at tilskynde til kodevurdering var en letvægt måde at løse problemet på.

For det andet, noget som svar på dette problem, er vi begyndt at skrive nogle enhedstest, der bare tåler kontrol af dataene i datafiler, eller for at kontrollere, at alle vores Django-skabelonfiler med succes pares som gyldige skabeloner. Især i tilfælde af datafiler ville disse normalt ikke være noget, vi ville forvente at teste, men da vi nu ønsker, at filerne skal kunne redigeres af folk uden kendskab til koden, kan de være praktiske til at fange enkle fejl .

Til sidst, som vi typisk bruger Python til vores datafiler, har vi fundet, at syntaksen ikke er særlig intuitiv og kan tage noget at vænne sig til. For at tackle dette har vi skrevet en dokumentation med lidt mere detaljeret end hvis den var skrevet til en ingeniør. Denne dokumentation er også i repo og kan redigeres af alle, så vi opfordrer ikke-ingeniører til at opdatere og præcisere instruktionerne, mens de lærer, og at lære hinanden at redigere bestemte dele af webstedet.

Bevæger sig fremad

Vi betragter dette eksperiment som en succes og fortsætter det i en overskuelig fremtid. Hvor vi designer datafiler, der kan redigeres, vil vi forsøge at inkludere detaljerede instruktioner i selve filerne, muligvis med eksempler på kopi / behageligt.

Vi prøver allerede nu at få vores testfejl til at have informative fejlmeddelelser med detaljer om, hvordan vi løser, hvor vi kan, men på grund af kompleksiteten i at tolke testoutput udsætter vi ikke i øjeblikket Jenkins for ikke-tekniske teammedlemmer, selvom de teknisk kan log ind med single-sign-on. Dette er måske den næste mulighed, vi har til at forbedre bidragoplevelsen, og noget, vi måske prøve i den næste batch af nye startere, der gennemgår selvstudiet.

Til slut vil jeg opfordre alle udviklere til at se, om der er muligheder i dine virksomheder til at få ikke-tekniske teammedlemmer, der bidrager til dine kodebaser. Der er fordele ved produktivitet på begge sider, mere empati mellem hold og en stærkere følelse af ejerskab over arbejde for dem, der ikke længere er afhængige af udviklere til at foretage ændringer for dem. Den reducerede friktion betyder også kortere feedbackcykler, som kan være transformerende for hvad andre kan udføre i deres arbejde, alt uden de høje omkostninger til udviklingstid på redigeringsgrænseflader.