Kildekontroll er måten å gå for programvareutvikling, og ved å bruke et repository hosting service kan du administrere koden enda mer.
I tillegg til de mange fordelene med Bitbucket som vi allerede har nevnt, kan du også sette opp webhooks for å automatisere prosesser og opprette alle slags varsler og samspill basert på handlinger utført i lageret ditt. I denne artikkelen skal vi se på hvilke webhooks er og hvordan du kan bruke dem, og vi vil gå gjennom et eksempel på implementering av kodeutbredelse via webhooks.
Når du utfører bestemte handlinger i et Git-depot, har du muligheten til å påkalle et gitt skript. Dette kalles en krok, og det finnes flere typer kroker i Git. Du kan for eksempel utføre et skript like før du foretar endringer i depotet, eller før du trykker på fjernlageret.
Disse eksemplene er for et lokalt lager. Men når du bruker et vertshotell, som Bitbucket, har du muligheten til å utføre webhooks. Disse ligner veldig på en Git-krok, men i stedet for å utføre et skript, sender du en HTTP-forespørsel til en gitt nettadresse, med nyttelast varierer basert på typen webhook.
Selv om det ikke er vanskelig, kan distribusjon av koden til en produksjonsserver være svært tidkrevende og et ekte skadedyr. Det er imidlertid et nødvendig skritt i enhver moderne applikasjonsutvikling. I et lokalt lager kan du opprette et skript som bygger koden hver gang du forplikter noe eller fusjonerer til din hovedavdeling, og når du arbeider med Bitbucket, bør dette ikke være annerledes. For å etterligne dette, vil vi dra nytte av Bitbucket POST-kroken.
Det første trinnet for å sette opp POST-kroken for et gitt lager er å ha depotet på plass. For denne opplæringen skal jeg bruke en modifisert versjon av Bootstraps Jumbotron eksempel. Du kan ta tak i lageret fra Bitbucket eller bare gaffel det i kontoen din. Dette eksemplet er det samme som Bootstraps Jumbotron, men bruker RequireJS og styrer avhengigheter via npm og Bower.
Når du har depotet på plass, er det på tide å sette opp POST-kroken. Gå til oversikten over varelager, naviger til innstillinger, og gå til kroker seksjon. For krok typen velg POST, og skriv inn nettadressen for å sende HTTP-forespørselen til når depotet er trykket. Dette er alt du trenger å gjøre på Bitbucket-siden for å automatisere distribusjonsprosessen via webhooks.
Når du har konfigurert POST-kroken for lageret ditt, er det neste du må gjøre, å få tak i forespørselen, og i dette tilfellet klon og bygge opp depotet i den offentlige HTML-banen. For dette skal vi bruke NodeJS med ExpressJS. La oss lage skriptet som skal håndtere kloning, installasjon, bygging og flytting av applikasjonen. Det er et bash-skript som vi kan utføre fra vår NodeJS-server.
# / bin / bash git klone $ 1 cd tuts-webhooks npm installere bower install node_modules / requirejs / bin / r.js -o build.js rm bygge / build.txt rm -rf / usr / share / nginx / www / tuts- webhooks.bitslice.net/html/* mv build / * /usr/share/nginx/www/tuts-webhooks.bitslice.net/html/. cd ... / rm -rf tuts-webhooks
Dette skriptet tar seg av alle trinnene som er nødvendige for å få søknadskoden, samt å bygge, optimalisere og flytte resultatet til serverens offentlige plassering. De $ 1
refererer til skriptets første argument, som i dette tilfellet er depotets nettadresse. Vær oppmerksom på at stiene er satt til banene på serveren min, og din sannsynlighet vil være annerledes, så oppdater dem for at skriptet skal fungere riktig.
Med dette skriptet på plass, kan vi kjøre det manuelt med lagringsadressen og få en produksjonsversjon av nettstedet vårt. Men vi vil ikke utføre det manuelt, og det er her NodeJS og Bitbucket POST-forespørselen vil skinne. La oss lage en server som vil svare på POST-krokforespørselen og utføre det forrige skriptet.
Beskriveren for serveren som vil håndtere POST-krokforespørsler, er som følger.
"navn": "WebHooksTutsPlus", "beskrivelse": "Serverprogrammet som brukes til å fange forespørsler, send fra Tuts Bitbucket Webhooks-depotet.", "versjon": "1.0.0", "privat": sant, "avhengigheter" "body-parser": "~ 1.0.x", "express": "4.xx"
De eneste avhengighetene for denne enkle serveren er Express og body-parser for håndtering av JSON-forespørsler nyttelast.
Nå for den faktiske NodeJS-serveren, går koden som følger.
var bodyParser = krever ('body-parser'), express = krever ('express'), app = express (); var site = krever ('. /routers/site'); app.use (bodyParser.json ()); app.use (bodyParser.urlencoded ()); app.get ('/', funksjon (req, res, neste) res.send ('Kroker lytter kjører');); app.use ('/ site', nettsted); app.listen (9090);
Dette er en veldig enkel webserver som lytter på lokalhostens 9090-port. På linje 10 har vi en metode som lytter på serverbasen URL og svarer med en tekstmelding bare for å verifisere at serveren kjører. Nå for skriptet som faktisk håndterer POST-kroken, legg til følgende skript og plasser det inne i _routers_
mappe.
var express = kreve ('express'), router = express.Router (); router.post ('/', funksjon (req, res, neste) var nyttelast = JSON.parse (req.param ('nyttelast')), repo = payload.canon_url + payload.repository.absolute_url, exec = 'child_process') .exec; exec ('./site.sh' + repo + 'site', funksjon (feil, stdout, stderr) ); res.json (melding: 'Nettsted oppdatert'); ); module.exports = ruteren;
Denne ruteren lytter etter POST-forespørsler til webadressen "nettsted". Det bygger bare repository URL fra forespørselen nyttelast og utfører vårt tidligere opprettet script med repository URL. For enkelhets skyld håndterer vi ikke utdataene fra NodeJS exec-metoden, eller kontrollerer feil i manuskriptet.
Det er det! Nå etter hvert trykk til lageret ditt, vil nettstedet ditt automatisk bygge, optimalisere og distribuere koden. Bare husk å gi det et par minutter å installere alle avhengighetene og kompilere koden.
OK, det er flott: vår side oppdateres automatisk når vi skyver endringer i depotet. Men akkurat nå validerer vi ikke noen informasjon når du utfører oppdateringsprosessen. En av de mest grunnleggende kontrollene som vi kan og bør utføre, er opprinnelsen til forespørselen, og Bitbucket gir oss IP-adressene som POST-kroken kan komme fra. Med denne informasjonen kan vi nå endre serveren vår for å bare forsøke å oppdatere nettstedet når forespørselen kommer fra denne opprinnelsen. Legg til følgende kode øverst i rutemetoden.
hvis (req.ip! = '131.103.20.165' && req.ip! = '131.103.20.166') res.json (melding: 'Uforstått opprinnelse'); komme tilbake;
Merk at hvis Bitbucket oppdaterte sine utgående IP-adresser, må vi oppdatere denne delen. En annen ting å ta i betraktning er at, i hvert fall i mitt tilfelle, bruker jeg nginx som omvendt proxy, så akkurat nå req.ip
samtalen kommer tilbake 127.0.0.1
og vil ikke fungere. For å fikse dette, må vi fortelle vår server å stole på proxyen og bruke den opprinnelige IP-adressen. Enkel nok: Vi trenger bare å legge til følgende kode over den første app.use ()
ring inn vår server.js.
app.enable ("trust proxy");
Og det er det, nå vår req.ip
vil gi den opprinnelige IP-adressen, og vi kan sjekke mot Bitbucks utgående adresser.
Dette eksemplet bruker en NodeJS-server til å håndtere forespørselen, og serveren lytter på localhost s port 9090. Derfor, for at dette skal fungere, bruker jeg nginx som omvendt proxy for å sende den eksterne forespørselen til NodeJS-serveren. Sette opp nginx som omvendt proxy er utenfor omfanget av denne opplæringen, men det er viktig å nevne og bruke en ekvivalent konfigurasjon når du følger med. Husk også å utføre npm installasjon
kommandoen før du starter serveren for første gang.
Gjennom hele denne serien har vi sett noen veldig kule muligheter og måter å dra nytte av Bitbucks evner. Og vi har nettopp ridd på overflaten av webhooks. Det er mange forskjellige utløsere og informasjon som tilbys av hver krok (les hvilken annen informasjon som er bestått i en Bitbucket POST-krok), slik at du for eksempel kan sette det opp for å få varsler når noen forker ditt lager. Eller på den mer avanserte delen av spekteret kan du opprette et mobilprogram for å få push-varsler når bestemte handlinger utføres.
Legg igjen kommentarer, spørsmål og annen tilbakemelding i kommentarfeltet nedenfor.