Utrulling til Live og Staging med Deploybot

Hvis du har vært i nettutvikling en stund, har du sannsynligvis skrudd opp en filoverføring mens du prøver å oppdatere et nettsted. I beste fall legger du til en haug med lett identifiserbare filer i en katalog, og du fjerner dem for å fikse feilen. Ja det koster deg tid og det er irriterende, men ingen skade gjort.

I verste fall overfører du en haug med temafiler på feil måte. Deretter må du finne ut hvilke som ble overskrevet, hvilke som ikke hører hjemme i det hele tatt, og hvordan i all verden vil du gjenopprette temaets fungerende tilstand.

I dag skal vi takle å løse dette problemet ved å bruke Git og Deploybot for å automatisere distribusjonsprosessen.

Hva er automatisk distribusjon?

En grunnleggende automatisert distribusjon har fire deler som vist i dette diagrammet.

De fleste utviklere starter med bare koden og serveren. De gjør endringer i arbeidskopien av nettstedet, og sender deretter endringene direkte til serveren via FTP. Verktøy som Coda eller Dreamweaver har direkte FTP-integrasjon slik at du kan gjøre dette fra innsiden av ditt kodemiljø.

Det neste trinnet mange utviklere tar er å legge til et oppsamlingssted slik at de ikke endrer live-serveren direkte. Du kan gjøre dette med noe sånt som VVV eller MAMP. Ofte betyr dette også at du bruker et versjonskontrollsystem som Git for å administrere endringene du gjør på din lokale arbeidsside.

Når du legger til et oppsamlingssted, legger du også til kompleksitet. Hvordan får du kodeendringene dine fra ditt lokale arbeidssted til et sted hvor klienten din kan se endringene? Ja, som jeg allerede har sagt, kan du bruke en grunnleggende FTP-klient som FileZilla, Overføre eller Gaffeltruck å flytte filene mens du gjør endringer, men dette er utsatt for feil, og det er her automatisering av distribusjonsprosessen vil spare deg for mye tid.

I stedet for at du tar filene du endrer og skyver dem til iscenesettelsesserveren din, bruker du et annet system for automatisk å oppdage endringene i Git-repositoriet ditt og skyver bare disse endringene til iscenesettelsen din klient kan bruke for å sjekke arbeidet.

Å lese:  Hvordan overvinne de 4 beste e-handelsutfordringene

Det etterlater fortsatt live-siden din som en manuell distribusjon, noe som er mye skumlere fordi det kan bety tap av ekte penger hvis du tar ned en live-arbeidsside. La oss i stedet anta at du skal sette opp distribusjonssystemet til automatisk å distribuere til iscenesettelse, og deretter vil systemet ditt distribueres med et enkelt klikk til live-miljøet når du er klar til å gå.

Så nå har du et system som ser slik ut.

La oss dykke inn så jeg kan vise deg hvordan jeg setter opp denne distribusjonsprosessen for hver klient jeg jobber med. Dette er trinnene jeg tar så snart jeg starter et nytt prosjekt. Jeg alltid sørg for at distribusjonsprosessen min er satt opp og fungerer før jeg begynner å gjøre noe annet arbeid på et klientprosjekt.

Hvordan strukturere Git-depotet ditt

Ditt første valg å ta er, hvilken katalog vil du sette opp den automatiske distribusjonen i? Med mindre klienten min spesifikt ber om den fulle kildekontrollen for WordPress-installasjonen deres, bruker jeg wp-innholdskatalogen for å sette opp det automatiserte distribusjonssystemet mitt. Det starter i terminal ved å utstede denne kommandoen som initialiserer et git-lager.

git init

Nå er det på tide å ignorere filene du ikke vil distribuere hele tiden. Dette er filer som sikkerhetskopifiler, bilder og alle de tilpassede prosjektfilene som mange koderedigerere legger til i en katalog. Du kan se min vanlige .gitignore-fil nedenfor.

config/app_config.yml

config/database.yml

config/*.sphinx.conf

config/s3_credentials.yml

*~

*.cache

*.Logg

*.pid

tmp/**/*

.DS_Store

db/cstore/**

db/sfinx/**

doc/api

doc/app

doc/plugins

doc/*.dot

dekning/*

db/*.sqlite3

*.tmproj

*.sw?

*.esproj

_notater*

dwsync.xml

podcast.xml

*.kpf

*laster opp/*

*.swp

*.idé

*.sublime-prosjekt

*.sublime-arbeidsområde

*/node_modules/*

tagger

*.bak

cache/*

managewp/*

mu-plugins/*

dp.php

updraft/*

språk/*

db.php

plugins/wp-rocket/cache.json

Legg gjerne til eller fjern fra denne etter behov. Nesten alle prosjekter jeg jobber med trenger en slags tilpasset oppføring for å ignorere en fil som er spesifikk for min lokale arbeidsside, som iscenesettelsen og live-sidene vil ha sin egen tilpassede fil jeg ikke vil overskrive.

Herfra er det på tide å sette opp grenene du trenger for å sette i gang distribusjonssystemet. Jeg bruker to hovedgrener. Først er mastergrenen som tilsvarer liveproduksjonsstedet mitt. For det andre er en gren jeg merker iscenesettelse og tilsvarer iscenesettelsessiden jeg vil at klienten min skal bruke som en måte å sjekke endringene vi gjør.

Å lese:  Hvordan koble høyt nivå til Shopify API

Når du initialiserte Git-depotet ditt, fikk du allerede mastergrenen din, så bruk denne kommandoen til å legge til en iscenesettelsesgren og sjekke den ut.

git checkout -b staging

Denne kommandoen oppretter og sjekker ut en ny gren. Hvis du er ny på git, kan du finne mer informasjon om de tilgjengelige kommandoene i Git dokumentasjon.

Nå må du skyve prosjektet inn i kildekontrollsystemet. Github og Bitbucket er to populære valg som begge fungerer med det automatiserte distribusjonssystemet vi skal bruke kalt Deploybot. Når du oppretter et nytt depot med begge sider, vil de gi deg videre instruksjoner for å legge til ditt lokale depot til din nettversjon i Github eller Bitbucket.

Setter opp Deploybot

Da jeg først begynte på mer komplekst arbeid som utvikler, anbefalte vennen min Duane Deploybot til meg da jeg klaget på nettet om å rote til manuell FTP-distribusjon. Det tok en rekke anbefalinger før jeg endelig gjorde det jeg ble fortalt, men jeg har nå vært en fornøyd Deploybot-kunde i årevis.

Selv om det er andre måter å distribuere nettstedene dine på, involverer mange av dem grensesnitt med Git Webhooks eller noen automatiserte distribusjonskonfigurasjonsfiler via koderedigeringsprogrammet. Det er mye kraft i de andre verktøyene, men hvis du akkurat har begynt med automatisert distribusjon, er det stedet å begynne med noe rett frem som Deploybot.

For å komme i gang registrer deg for en Deploybot konto og koble Github eller Bitbucket til kontoen din. Jeg bruker min eksisterende Bitbucket-konto i dag. Start med å legge til et nytt depot til Deploybot-kontoen din.

Når du har funnet depotet du vil konfigurere for automatisert distribusjon, klikker du på knappen merket koble til nederst på siden. Dette vil sende deg tilbake til depotsiden din mens Deploybot fullfører initialiseringen av depotet ditt. Vanligvis gjøres dette på et minutt eller to, så fyll opp kaffen og kom tilbake for å fullføre installasjonsprosessen.

Å lese:  Automatiseringer for WooCommerce-butikker

Når depotet ditt er satt opp, klikker du på det for å komme til hovedsiden. Siden vi ikke har noen sFTP-informasjon satt opp ennå, vil den ha en stor boks på den som forteller deg å sette opp en server. Klikk på knappen for å opprette et miljø og en server.

La oss starte med distribusjon til vårt iscenesettelsesmiljø. Så merk serveren din som staging. Velg automatisk distribusjon og sørg for at du setter grenen til iscenesettelse.

Når du er ferdig, klikker du på Lagre knappen nederst på siden for å gå til serverkonfigurasjonen.

Merk den på neste side som en Staging-server igjen og legg inn sFTP-informasjonen fra nettstedet ditt. Hvis du ikke er sikker på hvor du finner dem, les denne nyttige veiledningen.

Når du har lagt inn sFTP-informasjonen din, kan du bla ned til bunnen og lagre den. Deploybot vil deretter teste tilkoblingen din for å sikre at informasjonen du oppga fungerer. Nå er det på tide å gjøre vår første distribusjon for nettstedet for å sikre at alt fungerer. Jeg legger ofte til en test.txt-fil i distribusjonen som en enkel måte å bekrefte at distribusjonen fungerte som den skal.

For å starte distribusjonen til miljøhistorikken din og klikk distribuer.

Nå vil du se en side med den siste git-commit-meldingen din som notatet du vil se inne i Deploybot ved siden av denne distribusjonen. For store endringer vil jeg endre dette, men hvis jeg bare endrer CSS eller noe mindre, kan commit-meldingen bli værende. Siden dette er iscenesettelse, vil hver enkelt forpliktelse til vår iscenesettelsesgren bli distribuert automatisk, noe som betyr at forpliktelsesmeldingene dine er det som vises. Det er bare den første forpliktelsen vi trenger å gjøre manuelt til oppsetningsstedet vårt.

Bekreft nå at filene dine har blitt publisert til iscenesettelsen, og vi kan sette opp live-distribusjonen.

For live-distribusjon, sørg for at du ikke gjør det velg automatisk distribusjon og sørg for at du velger hovedgrenen som kilden til distribusjonen. Vi vil at dette skal være en manuell distribusjon når vi er klare til å pushe endringer på live-siden vår.

Å lese:  Hvordan forberede seg på plutselige stigninger i nettstedtrafikken

For å gjøre dette må du sjekke hovedgrenen din og deretter slå sammen endringene fra iscenesettelsesgrenen til master.

Du kan gjøre det med disse kommandoene.

git checkout master

git merge staging

git push origin master

Nå når du går til Deploybot-kontoen din, vil du kunne distribuere endringene manuelt akkurat som vi gjorde med vår første distribusjon til vårt oppsamlingsmiljø. For live-miljøet ditt, sørg for at du endrer distribusjonsmeldingen slik at den passer til endringene som blir overført til live-nettstedet ditt. Du bør også lage en sikkerhetskopi av nettstedet ditt. Du kan gjøre dette ved å gå til sikkerhetskopieringsnavigasjonen på nettstedet ditt og deretter lage en manuell sikkerhetskopi.

Det er det, du har ditt automatiserte distribusjonssystemoppsett for både iscenesettelser og live-miljøer.

Andre implementeringshensyn

Selv om dette systemet er et stort skritt fremover for de fleste utviklere, er det ikke uten problemer. Den største er at hvis du har en haug med endringer, venter du fortsatt på at FTP skal fullføre overføringen av filer som har endret seg. Dette kan bety at noen besøker nettstedet ditt og at ikke alle filene nettstedet ditt trenger for å kjøre er tilstede.

For mange kunder vil dette ikke være et problem, men hvis det er for nettstedet ditt, må du se på å sette opp et Atomic-distribusjonssystem. Denne typen distribusjonssystem flytter alle filene, verifiserer at de fungerer som de skal og endrer deretter filinnstillingene på serveren din slik at den nye katalogen nå er den som kjører nettstedet ditt.

Prosessen med å koble til en ny mappe tar så kort tid at bare en datamaskin vil legge merke til det. Det betyr også at hvis du finner et problem senere, kan du endre systemkoblingen tilbake til den gamle versjonen av nettstedet for å gå tilbake til versjonen som fungerte. Dette tar igjen bare svært kort tid og reduserer nedetiden.

Uansett hva du velger å gjøre, slutt å bruke en FTP-klient for å distribuere klientfilene dine i dag. Den lille månedlige kostnaden for Deploybot gjenvinnes hver gang du ikke gjør det gjør en feil når du distribuerer filene dine.

Nye publikasjoner:

Anbefaling