Hvordan GitHub blev forbindelsen mellem softwareautomatisering

Video: Hvordan GitHub blev den de facto automatiserede forsyningskæde til software

At ringe GitHub en hjemmeside er at kalde Italien for et spisested. GitHub er den førende udøver af en ny markedsplads - og ja, det kan med rette kaldes et "marked", fordi det genererer indtægter. Det tjente efter flere skøn over $200 millioner i omsætning i 2017 og var åbenbart værdifuldt nok for Microsoft til at få det til at at købe GitHub direkte, i en handel med 7,5 milliarder dollars i juni sidste år.

Læs også: Hvorfor Microsoft køber GitHub: Det handler om udviklere

Det er præcist og retfærdigt at sige det GitHub skabt et marked for udbud af open source software, og automatiseringen af ​​dens implementering. Der er andre konkurrenter på dette marked, især GitLab og Atlassians Bitbucket. Det er tilstedeværelsen af ​​disse aktører, der legitimerer dette marked.

Hvad GitHub er blevet til, er det mest effektive eksempel til dato på en webservice, der absorberer funktionen af ​​en hel industris forsyningskæde. Open source software er tidligere blevet delt online, hvor SourceForge er en af ​​de mest effektive behandlere. Men distributionen af ​​software gennem SourceForge, og websteder som den, foregår ved hjælp af et indholdsstyringssystem - en platform, der er bedst egnet til folk, der bruger webbrowsere.

Kom i gang

GitHub er udviklet til at bruge et værktøj skabt til Linux kaldet git, af manden, der selv skabte Linux, Linus Torvalds. Det er en automatiseret forsyningskæde til distribution af open source-software, både mellem de mennesker, der udvikler det, og for de mennesker, der bruger det. Dens automatisering sikrer, at distributionskanalen leverer den nyeste, sikreste version, der er tilgængelig for brugerne, samtidig med at mindre stabile værker i gang distribueres til udviklere. Det giver også de mest stabile versioner af andre komponenter, som et delt kodeelement kan afhænge af.

Læs også: Linus Torvalds om Linux, livet og badekåber

"Skyen er i stigende grad en kerneprioritet for udviklere. Og hos GitHub bør alt, hvad vi gør, handle om at gøre en udviklers liv bedre på alle stadier af deres arbejde og livscyklus," sagde Nat Friedman, kommende GitHub CEO, under en fælles pressekonference med Microsoft i juni. "Det inkluderer at hjælpe dem med at gøre det nemmere at bygge i skyen.

"GitHub er en åben platform," fortsatte Friedman. "Så vi har mulighed for, at alle kan tilslutte deres cloud-tjenester til GitHub og gøre det nemmere for dig at gå fra kode til sky. Og det strækker sig også ud over skyen: Kode til mobil, kode til kant-enhed, kode til IoT. Hver arbejdsgang, som en udvikler ønsker at forfølge, vil vi støtte."

Linus Torvalds' hensigter

Git-værktøjet er ikke, i modsætning til hvad du kan læse andre steder, en eksklusiv del af Linux. Ja, versioner til Windows og Mac OS X distribueres frit. Teknisk set er git (som heller ikke er et akronym, der står for noget bestemt) introduceret som et distribueret versionskontrolsystem. Oprindeligt lavet til Linux-kommandolinjen, etablerer det et arkiveringssystem bortset fra computerens eget filsystem, hvor flere versioner af en udviklende fil kan gemmes og hentes. Databasen, hvor disse versioner udveksles, kaldes et repository (eller "repo" for kort). Enhver version af en fil, der lægges i et lager, kan udtrækkes fra den i samme tilstand. Fra git's perspektiv behøver dette ikke at være software. Det kan være manuskriptet til en bog, brugsanvisningerne til separate versioner af en maskine i udvikling eller en persons dagbog.

Torvalds skrev den originale git som et kildekodestyringssystem for sine egne personlige bidrag til Linux-kernen. En del af hans inspiration var et eksisterende lagerbaseret versionskontrolstyringssystem kaldet Concurrent Versions System (CVS). Hvis du husker den ældgamle verden af ​​disk-baserede databaser, blev låse pålagt poster, der var bliver hentet og potentielt opdateret for at sikre, at ikke to klienter har forskellige syn på det samme optage. CVS havde et lignende koncept ved hjælp af et lager af indholdsversioner, der gaflede sig fra hinanden som grene af et træ. En filial kan blive "tjekket ud" af en person, der ønsker at foretage opdateringer eller ændringer. Når først disse ændringer var foretaget, ville en revideret version af indholdet blive flettet tilbage i stammen, men i stedet for at beskære den gamle gren, ville et mærke markere dens oprindelige placering, hvilket gør det muligt at genskabe den, hvis nødvendig.

Læs også: Linux-skaber Linus Torvalds: Det er det, der driver mig til vanvid

Mere til sagen hadede Torvalds CVS. Men det alternativ, han havde valgt til at vedligeholde Linux, var et stykke proprietær software kaldet BitKeeper. Det kan have været det første virkelig skalerbare indholdsopbevaringssystem. Alligevel ejede det nøglerne til sit eget kongerige -- specifikt metadataene, der beskriver historien om bidrag til et depot. Disse metadata er helt afgørende for konstruktionen af ​​en operativsystemkerne, men var kun tilgængelige for BitKeeper-licenserede brugere. BitKeeper udvidede en sådan licens til Linux-bidragydere på skrivebeskyttet basis.

Når en anden Linux-bidragyder tilsyneladende forsøgte at reverse-engineere metadataene for sig selv -- en handling, der Torvalds ville offentligt fordømme -- BitKeepers udgivere rev licensen og efterlod Torvalds til enten at kæmpe med CVS i stedet for eller udtænke et alternativ.

Fra et centraliseret til et distribueret lager

Det alternativ, git, ville styre uden om BitKeepers centraliserede lager og i stedet vælge en distribueret model. Et resultat af denne model er, at et væld af bidragydere kunne tilbyde deres egne opdateringer til en filial uden nogle vilkårligt udpeget overklasseperson, der får "commit access" - retten til at erklære et sådant bidrag som "officielle" en.

Læs også: Git: Et snydeark - TechRepublic

Som Torvalds fortalte en Google-sponsoreret konference i maj 2007, undgår den distribuerede model målrettet den form for politik, der endte med at ødelægge hans indsats med BitKeeper.

"Da du ikke ønsker, at alle skal skrive til det centrale lager, fordi de fleste mennesker er idioter," sagde han til sit publikum, "skaber du denne klasse af mennesker, som tilsyneladende ikke er idioter. Og det meste af tiden, hvad der sker, er, at du gør den klasse for lille, fordi det er virkelig svært at vide, om en person er klog eller ej - og selvom du gør den for lille, vil du have problemer. Så hele dette commit-adgangsproblem -- som nogle virksomheder er i stand til at ignorere ved blot at give alle commit adgang -- er en enorm psykologisk barriere, og forårsager endeløse timers politik i de fleste open source projekter."

Med vilje eller ej var Torvalds' arkitektoniske beslutning katalysatoren for den bevægelse, der forvandlede open source fra en revolution til et etablissement. "Åbenhed" gav aldrig mening i et samfund med et mere mystisk organisatorisk hierarki end den gennemsnitlige virksomhed. Ved hjælp af en distribueret lagermodel kunne enhver person - selv en anonym - kræve en forgrening af et eksisterende projekt og bidrage med de ændringer, der er nødvendige for at gøre denne fork til sin egen.

Logger ind

Hvad GitHub bidrager til dette billede er disse vigtige komponenter:

• Den sociale ramme for koordinering af git blandt flere brugere;
• Et grundlæggende identitetssystem for individuelle bidragydere (i modsætning til deres arbejdsgivere eller deres projekter);
• Et grundlæggende websted, hvormed softwaren (eller andet indhold) kan præsenteres og forklares for omverdenen;
• Konteksten for projekter, der skal integreres med kontinuerlig integration (CI) pipeline platforme som f.eks Travis CI, CircleCI, og Jenkins.

En af de vigtigste udfordringer, som open source-samfundet stod over for gennem dets formative år, var, ganske ironisk nok, manglen på en fælles, programmerbar infrastruktur, der spænder over hele dens bidragydere. Ja, de havde indholdsstyringssystemer, men de var ikke virkelig skyer, og de var heller ikke systemer udviklet til distribution og udrulning af software.

Læs også: Googles leder siger, at det er OK. Microsoft nappede GitHub - CNET

Selvom dette måske ikke var Torvalds' oprindelige hensigt, resulterede parringen af ​​git på udvikleres pc'er med GitHub på nettet i et let automatiseret system, hvorved enhver person kan deltage i et massivt samarbejdsprojekt, selv uden en invitation. Ethvert GitHub-medlem kan gafle et open source-lager. Hun kan derefter vælge at klone den til sin pc lokalt (forking er ikke det samme som kloning, på trods af hvordan nogle tutorials formulerer dette).

Dernæst GitHub-bruger konfigurerer git at pege på det depot. Alle ændringer, hun foretager, vil skabe nye versioner af depotet. En sådan ændring vil ikke fysisk klone hele depotet, men det vil producere et nyt billede, der effektivt fusionerer ændringerne med originalen. Hun kan eksperimentere ved at lave grene -- evolutionære veje, der afviger fra hinanden, især for at teste mange metoder til at opnå et resultat.

Træk anmodningen

Bidragshandlingen - at anmode om, at ændringer eller (formentlig) forbedringer begås eller fusioneres, enten opstrøms eller til en andens lager -- er den proces, du måske har hørt om, kaldet en pull anmodning. Dette er den vigtigste sociale proces i hele systemet. Det er et middel for en bidragyder at bede ejeren af ​​et andet depot – normalt vedligeholderen af ​​projektet – om at evaluere de ændringer, hun har foretaget, og enten acceptere dem og flette dem ind i sit eget lager eller afvise dem, da han finder det passende.

Læs også: Lær at bruge GitHub med GitHub Learning Lab

Det er måske ikke en tilfældighed, at GitHub bruger forkortelsen "PR" til at referere til en pull request (vi journalister tror umiddelbart det betyder "pressemeddelelse"). En social etikette har dannet sig omkring den rigtige metode til at introducere en pull-anmodning til fællesskabet, især for at gøre det mere tiltalende end en kontaktanmodning på LinkedIn. Brugere bliver rådet til at være mere venlige, mere overbevisende, mere - for at lave en sætning - "åbne" om hensigten med de ændringer, de forsøger at foretage. Det er et forsøg på at fastholde det menneskelige element i open source-processen i stedet for at antage, at folk har det lige så fint med almindelig vanilje-automatisering.

"Pull-anmodninger kan ske i enhver workflow, du bruger, når du vil inkorporere ændringer i din kodebase," forklarede GitHub-træner Eric Hollenberry (billedet til højre ovenfor) under en virksomhedskonference i 2016 til en deltager og GitHub-medlem, der ikke vidste, at der fandtes pull-anmodninger. "En pull-anmodning er per definition en samtale omkring en forandring. Du opretter den samtale på et hvilket som helst tidspunkt, du ville bruge i din arbejdsgang, og så ville det resultere i en ændring, som du smelter sammen i, til sidst."

Docker-faktoren

GitHubs magt til at opmuntre en vidt forskellig forsamling af bidragydere nåede kritisk masse med introduktionen af ​​containerisering. Før standardiseringen af ​​containere af Docker var det vigtigste middel til at dele kode online gennem et almindeligt komprimeringsformat såsom TAR eller ZIP. Der var automatiserede scripts overalt for at få og lægge bidrag fra og til iscenesættelse. Men "overalt" er et svært sted at patruljere og styre. Nogle SourceForge-brugere brugte plug-ins til deres respektive udviklingsmiljøer (deres IDE'er), såsom Eclipse. Og disse plug-ins ville blive standardiseret på en måde, men kun med hensyn til disse IDE'er.

Som et filformat er Dockers container ikke noget særligt nyt eller nyt. Den bruger en form for ZIP-komprimering (baseret på Lempel-Ziv), der er så tæt på standarden, at UNZIP-værktøjer kan give mening ud af det. Men det er indholdet af den beholder, der var så revolutionerende, især medtagelsen af ​​noget, der hedder a Dockerfil. Det er en slags manifest med instruktioner til, hvordan man komponerer og implementerer softwaren inde i containeren. Disse instruktioner kan udføres automatisk af Dockers eget Compose-værktøj, og de inkluderer instruktioner om, hvordan man erhverver, udpakke og implementere alle de andre komponenter, som softwaren er afhængig af, uden at skulle inkludere dem i containeren pakke. Disse instruktioner involverer repositories, og Docker Inc.s egen hedder Docker Hub.

Læs også: Hvad er Docker, og hvorfor er det så pokkers populært?

Det Dockerfil udfyldt et stort hul i automatiseringsprocessen for GitHub og andre online repository-systemer baseret på git. I stedet for at stole på deres egne manuskripter (eller ironisk nok igen, som de havde delt med hinanden) iscenesætte og implementere deres software, som SourceForge-brugere skulle gøre, brugte de et middel, som alle frit kunne adoptere. Dette gjorde software opnået gennem pull-anmodninger både anvendelig og testbar i en isoleret kontekst, der ikke ville forstyrre anden software, herunder andre pull-anmodninger.

Hvad stewarderne af open source-projekter endelig havde til rådighed for dem, var et middel, hvormed de kunne evaluere og godkende andres arbejde, og lede processen med at begå deres arbejde opstrøms, uden egentlig at skulle tænke på processen meget.

Business case

Så hvor, i handlingen med at automatisere al denne gratis deling af software mellem gratis individer frit, kommer de $200 millioner af årlige indtægter ind i billedet? Hvad GitHub indså - i dette tilfælde helt med vilje - var, at den nøjagtig samme mekanisme, der blev brugt til at forene den bredere open source community for fælles projekter, kunne automatisere private virksomheders egne interne bestræbelser på at producere deres egen software, open source el ikke. Faktisk kunne GitHub Enterprise udnytte open source-fællesskabets infrastruktur som en platform for samarbejde i open source stil, men ikke nødvendigvis med det formål at opnå en open source licens.

Det var her, implementeringsplatformen blev en industri. Det private lager er ved at blive det cloud-baserede distributionscenter for virksomhedsudviklere, og virksomheder er villige til at betale abonnementsgebyrer for at få det.

Læs også: Docker har hovedpine i forretningsplanen

Og ja, det er her et open source-projekt skæres direkte ind i et af Microsofts vigtigste profitcentre. I årevis har samarbejde og versionskontrol været ingredienserne, der berettiger Microsoft til at opkræve præmier for Visual Studio Team Foundation Server og senere for Visual Studio Team Services. Ligesom CVS for længe, ​​længe siden, er Visual Studios native versionskontrolsystem dog centraliseret i 2013 vedtog det git som et distribueret alternativ. Alligevel har VS tilbudt et sofistikeret, meget grafisk styringssystem til kodeevalueringer og forpligtelser.

Omfavne og udvide redux?

Microsofts opkøb af GitHub har bestemt i det mindste en vis lighed med "omfavn og udvide" forretningspolitikker af sin ikke-så fjern fortid. For halvandet årti siden var der en overskrift, der pralede med et sådant opkøb ZDNet eller Betanews (mit gamle tilholdssted) ville have snesevis af læsere til at græde, "sammensværgelse!"

I dag hører du stadig nogle skrig, men du er nødt til at jage dem. "Da jeg læste om dette, tænkte jeg, fantastisk, nu vil de spore alles downloads," skrev en Reddit-bruger. "Nu tror jeg, de vil spore, annoncere og sælge alles downloadoplysninger."

Læs også: GitHub: Ændringer i EU's ophavsretslovgivning kan afspore open source

Men den kommentar blev begravet under adskillige andre kommentarer, hvoraf mange indrømmede ligegyldighed, hvoraf nogle få støttede Microsofts tiltag direkte. Virksomheden er allerede blevet en væsentlig bidragyder til både Linux og Kubernetes, og for de udviklere, hvis forhold til open source-bidragydere er blevet mere intimt af GitHub, Microsoft er lige så meget en del af deres lever som Red Hat.

"At købe GitHub betyder ikke, at Microsoft har engageret sig i et uhyggeligt plot om at eje de mere end 70 millioner open source-projekter på GitHub," skrev Linux Foundations administrerende direktør Jim Zemlin juni sidste år. "De fleste af de vigtige projekter på GitHub er licenseret under en open source-licens, som omhandler intellektuel ejendomsret. Varemærket og andre IP-aktiver ejes ofte af en non-profit som Linux Foundation. Og lad os være helt klare: Udviklernes hjerter og sind er ikke noget, man køber - det er noget, man tjener."

Beskyttelse af ideen

Open source-licenserne omkring projekter, der er betroet til GitHub-lagre, beskytter dem allerede mod enhver organisation eller anden individuel enhed, der hævder ejerskab over dem. Ligesom Googles 2006-opkøb af YouTube ikke overførte ejerskabet af deres possums-chasing-squirrels-videoer, vil Microsofts tilsyn med GitHub ikke ændre den juridiske status for de projekter, den er vært for.

Læs også: GitHub: Et snydeark - TechRepublic

Hvad der dog fortjener yderligere undersøgelse som tiden går, er hvordan denne aftale ved at legitimere open source leveringspipeline som en top-tier industri, vil ændre karakteren af ​​open source bevægelse. Hvis det nogensinde virkelig har været en modkultur, er det bestemt ikke en nu. Selvom GitHubs rentabilitet måske ikke direkte skyldes populariteten af ​​delekode, er den faktisk bundet til den automatiserede, pipelinede forsyningskæde, som open source gav anledning til. Hvis denne model virkelig er så indflydelsesrig, som open source-tilhængere hævder, at den er, så skulle intet Microsoft ville gøre for at ændre den på den ene eller den anden måde i det lange løb, skulle have nogen mærkbar effekt.

Lær mere -- Fra CBS Interactive Network

• Hvad Microsoft køber GitHub betyder for open source softwareudvikling af Steven J. Vaughan-Nichols, Linux og Open Source
• GitHub: Ændringer i EU's ophavsretslovgivning kan afspore open source-distribution af Scott M. Fulton, III, Open Source
• Microsofts 'fremtidige administrerende direktør for GitHub' udtaler sig om Atom og holder GitHub uafhængig og mere af Mary Jo Foley, Alt om Microsoft
• Linux Foundation: Microsofts GitHub-køb er en gevinst for open source af Liam Tung, Enterprise Software

Andre steder

• Open Source-udviklere, på vagt over for Microsofts afventende GitHub-overtagelse, overvej en 'Plan B' af Scott M. Fulton, III, The New Stack
• Hvordan Microsoft smedede en skalerbar Git for bedre at administrere Windows-udvikling af Joab Jackson, The New Stack
• GitHub: Kontoopsætning og konfiguration -- Kapitel 6.1 af Pro Git af Scott Chacon og Ben Straub, udgivet af Apress, men frit udgivet online

Relaterede historier

• Microsofts største udfordring med GitHub: At overvinde sin fortid
• GitHub: Vores afhængighedsscanning har fundet fire millioner sikkerhed
• GitHub siger, at fejl har afsløret nogle almindelige tekst-adgangskoder