Share
En gang var det en fil. Det var på datamaskinen, og du ønsket å få det på en server.
Noen gang lurt på hvorfor det er så mange måter å gjøre det på? Vi vil forklare noen av grunnleggende om distribusjon i denne artikkelen, slik at du forstår når du skal bruke hva. La oss komme i gang!
FTP, eller Filoverføringsprotokoll, anses av mange å være den gamle skolens måte å "sette opp et nettsted." Det er en protokoll som i utgangspunktet betyr at det er et sett av regler som både den lokale datamaskinen og vertsmaskinen er enige om, og kan sende meldinger gjennom. FTP er ikke et "program" i seg selv, men heller som en telefonlinje.
Så, hvis FTP er en telefon på grunnskolen (som fortsatt fungerer fint), er SFTP som et 4G-nettverk
Det gir en ny protokoll for de to maskinene til å snakke (ikke at det er nødvendigvis raskere, men). SFTP drives av SSH, som i hovedsak krypterer meldingene som sendes mellom de to maskinene; slik at eventuelle ondsinnede tredjeparter eller usikre nettverk ikke kan få tak i dine rådata under overføringen.
Hvis du ikke fanget det, er FTP og SFTP begge filoverføringsprotokoller. SFTP (og andre SSH-drevne overføringsprotokoller) overfører imidlertid filer og krypterer overføringen. "Jeg trenger ikke kryptering", kan du si. Mange mennesker tenker på samme måte; Fremtidsutviklere og moderne verktøy vil imidlertid lene seg mot sikrere metoder. Du har hørt det før - Bedre trygg enn beklager.
Men jeg har ikke lyst til å gå gjennom trøbbel.
Først av alt, hvis dette er din jobb, sug det opp. Du kan enten holde fast med din komfortsone (du vet, FTP fungerer fortsatt, akkurat som fasttelefonen din). Men vil du ikke bli bedre? Tross alt, det er derfor du er her, ikke sant?
Nå, hvis du fortsatt er litt lat, men som ideen om enkel adopsjon, kan du bruke SFTP med nesten hvilken som helst FTP-klient der ute. Det er sikrere. Pass på at serveren din støtter SSH (port 22, vanligvis, må være åpen), og du bør være god å gå. Men poenget med denne artikkelen er ikke å få deg til å tenke på kryptering og overføring av sikkerhet; det er å få deg til å tenke på en mer robust distribusjonsstrategi.
"Men jeg har ikke lyst til å gå gjennom trøbbelene.". Hvis dette er din jobb, sug det opp
Hvis du har utviklet seg en stund, har du sannsynligvis gått gjennom boreen for å opprette et nettsted og stadig dra og slippe filene dine til FTP-klienten din (eller dobbeltklikk, eller trykk på "synkroniser", eller ...). Dette er Teknisk en distribusjonsstrategi, men ikke en veldig robust. Selvfølgelig, mange ganger vil denne typen strategi fungere bra, spesielt hvis du er den eneste personen som noen gang vil berøre filene, og du har aldri overskrevet eller slettet en viktig fil. Men igjen, du er her for å bli bedre, ikke sant? Og du er en tryllekunstner.
Utplassering, i sin enkleste form tar noe kode og gjør det til "live" kode. Ved å overføre en index.html filen inn i serverkatalogen din, du distribuerer. Faktisk, på slutten av dagen, flyttes alle distribusjonsstrategier (med mindre du bruker et kompilert appsystem) i hovedsak filer eller versjoner av filer til "nåværende arbeidskatalog", eller endre de som allerede er der. For eksempel kan du gjøre endringer i det samme index.html filen direkte på serveren, og det ville effektivt "distribuere" disse endringene til offentligheten. Men distribusjon kan være mye mer.
Har teamet ditt noen gang opprettet et system som krever at du informerer alle når du har trykt en fil på serveren via FTP? Eller kanskje må du starte en Django eller Railserver etter endring av kode. Hvis du gjør dette som en del av rutinen for å gjøre nettstedet ditt gjenspeiler endringene du har gjort, er det en del av distribusjonsprosessen din.
Så, hvis distribusjon betyr å lage et sett med kode og filer live, hvordan kan det være mye mer enn SFTP? "Hva er Git, og hvorfor skal du bryr deg?" du spør. Git er et versjonskontrollsystem, eller en VCS. Det er en av mange VCSs som vi har skamløst plukket som vår favoritt. Vi forklarer hvorfor senere, men først snakkes om hva Det er.
Versjonskontrollsystemer utfører mange oppgaver, men det viktigste er å gi et sikkerhetsnett for utviklere - spesielt utviklingsgrupper. Vi nevnte tidligere hvordan FTP og SFTP kan være helt bra hvis du er perfekt, og du vil aldri overskrive en fil eller slette en viktig mappe utilsiktet. Men hvis du ikke har gjort dette ennå, ikke bekymre deg - det vil skje før eller senere. Det er nesten sikkert at det har skjedd med teamet ditt hvis du ikke har funnet ut et løsnings system. Men selv disse løsningen er en smerte. For eksempel har CSS-katalogen din alltid sett slik ut?
I så fall holder du versjoner av stilark som til slutt vil slå sammen sammen. Forresten gjør Git dette, men det gjør det mye bedre, raskere og mer robust enn du kan på egen hånd. Beholder du en annen CSS-fil hver gang du gjør noen endringer? Bare hvis du vil komme tilbake til nøyaktig hvordan den filen var på et bestemt tidspunkt? Selvfølgelig gjør du det ikke. Men Git vil gjøre akkurat det for deg, og du har ikke et rot av strekte filer og uklare navngivningssystemer overalt. Utover dette er Git smart nok til å vite hvordan du skal ta med deg styles.css fil og slå sammen med Mary eller John styles.css fil. Videre er Gits versjoner ikke hele filene; i stedet lagres de i deltaer, som i hovedsak er en lavnivåkodrepresentasjon av forskjellene mellom en fil og en annen fil. Dette betyr at forskjellige versjoner er mye mindre, og mye raskere å overføre når det kommer tid til å distribuere dem.
Men ingen av dette har noe å gjøre med distribusjon, du sier? Du har rett, versjonskontrollsystemer gjør i stor grad rett og slett hva deres navn antyder: hold versjoner i orden. Men de har også muligheten til å kommunisere gjennom de forskjellige protokollene vi har diskutert før. Git kan lese gjennom HTTP og lese og skrive gjennom SSH. (Les mer om overføringsprotokollene her.)
Så hvis Git har disse direkte tilkoblingene via overføringsprotokoller, kan du trykke versjoner frem og tilbake med teamet ditt via en lokal server, GitHub eller din egen live-server. Og det er slik Git passer inn i distribusjon. Du presser koden din, Mary og John trykker på koden, og den som har ansvaret for distribusjonen på teamet ditt, logger seg på serveren og slår koden i livemiljøet. Git tilbyr muligheten til å ha flere destinasjoner og grener av kode for å trykke forskjellige versjoner til forskjellige steder. En vanlig praksis er å ha en "staging" -server, der koden er trykket for å sjekke den i et levende miljø på et privat utviklingsdomene. En annen mulig arbeidsflyt er å aldri koble lagets lokale lagerbeholdninger til live-depotet, og i stedet bare tillate oppsamlingsmaskinen muligheten til å presse til live-serveren. Dette skaper et system for gjennomgang som ikke kan hoppes over.
Ulike versjoner er mye mindre, og mye raskere å overføre, når det kommer tid til å distribuere dem.
Utover oppføring, grener, flere distribusjonsdestinasjoner og robust versjonskontroll, tilbyr Git kroker, som "post-mottak", som kan utføre enhver form for handling du kan kaste sammen. Kanskje du vil ha en "edderkopp" -gren, der når koden kommer til ett punkt på serveren, skyver postmeldingen den koden på flere steder (fjern eller ellers). Enda videre, ved hjelp av en plattform som GitHub, er det et flott grafisk grensesnitt for å sette opp kroker. Fortell GitHub om å sende deg e-post (eller hvis du er kreativ, koble til en Growl-melding) hver gang du mottar et trykk fra et lagmedlem, for eksempel.
Det er bokstavelig talt tusenvis av måter å utvikle en distribusjonsstrategi med Git. Du kan raskt se at bruk av VCS for distribusjon gir noen svært omfattende fordeler, beskyttelse og kraft til distribusjonen din. Når du tar deg tid til å lære nok om Git for å få en arbeidsflyt på plass (og gjøre noen feil med det), vil utviklingsprosessen din ha det gøy.
Følgende kommandoer vil sette opp et lager på en ekstern maskin, sette opp et lager på din lokale maskin, legge til fjernregisteret som "opprinnelse", sjekk ut en gren kalt "mybranch" som vil bli slått sammen på serveren, skyver "mybranch" til fjernkontrollen, "opprinnelse", og til slutt logger tilbake til serveren for å slå sammen "mybranch" med standard "master" -grenen.
lokal> ssh brukernavn@remotemachine.com ekstern> CD-sti / til / prosjekt fjern / sti / til / prosjekt> git init ekstern / sti / til / prosjekt> avslutte lokal> CD sti / til / lokalt / prosjekt lokalt / sti / til / lokal / prosjekt> git init lokal / bane / til / lokal / prosjekt> git add. lokal / sti / til / lokal / prosjekt> git commit -m "initial commit" lokal / sti / til / lokal / prosjekt> git kassa mybranch lokal / sti / til / lokalt / prosjekt> git ekstern legg til opprinnelse brukernavn@remotemachine.com : sti / til / prosjekt lokal / sti / til / lokal / prosjekt> git push opprinnelse mybranch lokal / sti / til / lokal / prosjekt> ssh brukernavn@remotemachine.com ekstern> CD sti / til / prosjekt fjern / sti / til / prosjekt> git fusjon mybranch
Utover å lage din egen Git-drevne arbeidsflyt og integrere den i din egen server, kan du benytte andre gratis tjenester, for eksempel Heroku ;. Heroku er en hosting løsning som lar deg kjøre noen få linjer fra din Git-kontrollerte app, og distribuere den til "cloud" (i dette tilfellet en ekstern klynge av Linux-servere) over Git med nesten ingen innsats. Ta et par minutter for å få noen ting konfigurert, og du er på rase med bare noen få linjer med kode for enkel distribusjon. Seriøst ser det ut som noe slikt.
# gjør noe arbeid, hold det versjon-kontrollert med Git ... så> heroku opprette - stakk Cedar # - Stack Cedar gjør det i utgangspunktet mulig å lage flere typer programmer, inkludert PHP og Node # ... Heroku vil fortelle deg at det skaper ting , så vil det fortelle deg at det ble lagt til en fjernkontroll til din git repo> git push heroku master # og det er det! Åpne den distribuerte appen i nettleseren din> heroku åpen
Andre lignende verktøy inkluderer Pagoda Box, som er fokusert på LAMP-baserte arkitekturer, og AppFog og PHPFog, som er veldig lik Heroku.
Så lenge det ikke er noen feil i konfigurasjonen din, og du har fulgt Heroku's retningslinjer for hvordan du konfigurerer apper, kan du få Rails, PHP eller Node apps oppe og kjører om noen få øyeblikk. Å, og nevnte vi at du kan lage enkle Heroku-drevne apps gratis? Det er ikke før du oppgraderer til flere forekomster eller minne, eller trenger å legge til en database, som du påtar kostnader fra Heroku. Andre lignende verktøy inkluderer Pagoda Box, som er fokusert på LAMP-baserte arkitekturer, og AppFog og PHPFog, som er veldig lik Heroku. Disse alternativene tilbyr lignende tjenester og Git-integrasjon, med ulike prisstrukturer. Alle tre tilbyr et gratis alternativ for begrenset servereffekt. Disse er åpenbart gode fordeler, ettersom det tar mye tid å investere for å få din egen server satt opp med mer involverte applikasjonsarkitekturer som Rails eller Node. Utover det blir scaling veldig enkelt, da alle tre av disse tjenestene tilbyr lastbalansering og skalering til flere forekomster ved et enkelt klikk. Disse tjenestene tar vare på den heftige serveradministrasjonen for deg, slik at du kan fokusere på å lage apper, og vite at det er en veldokumentert, sikker og rask distribusjonsstrategi som du kan bruke når du er klar til å bli offentlig.
Forhåpentligvis har denne artikkelen fjernet litt forvirring om forskjellene mellom Git (og andre VCSer) og FTP / SFTP, og hva begrepet distribusjon betyr. Også, jeg håper at dette har oppmuntret deg til å utvikle din egen distribusjonsstrategi, med hjelp av verktøy som Git og Heroku. Hvis du allerede har en strategi, hva slags ting gjør du under distribusjon?
Accentsconagua