Moderne distribusjoner for WordPress-nettstedene dine

Hvis du er som meg, var din første erfaring med å skyve filer til en webserver enten gjennom en nettbasert filbehandling som cPanel eller en File Transfer Protocol (FTP)-klient som Transmit eller Filezilla. Koble til serveren, dra filen(e) over og vent til overføringen er fullført.

Enkelt, ikke sant?

Men så snart jeg begynte å jobbe med noe mer komplekst enn statiske HTML-filer, ble distribusjonen av koden langt mer kompleks: hva skjer hvis jeg savner en fil som kreves av andre, eller et semikolon i en global inkludering og den hvitskjermer hele siden? Hva om et avgjørende trinn blir savnet under prosessen?

Disse “cowboy-kodingsproblemene” blir bare verre ettersom flere mennesker, miljøer og avhengigheter blir involvert. Som et resultat blir det vanskeligere og vanskeligere å fortsette å gjøre fremskritt mens du sjonglerer med alle disse bevegelige delene. Det verste av alt er at frigjøring av kode blir en konstant kilde til angst.

Etter hvert som applikasjonene, nettstedene og butikkene våre blir mer modernisert, bør vi også modernisere distribusjonene våre. Fra versjonskontroll til kontinuerlig levering, en moderne utgivelsesprosess kan lindre angsten rundt distribusjoner.

Spore endringer med versjonskontroll

Det første trinnet i å gå bort fra ad-hoc-oppdateringer og cowboy-koding er å få nettstedet ditt under versjonskontroll, ved å bruke et verktøy som Git.

Å bruke versjonskontroll betyr at du vil kunne se hva som har endret seg, hvem som har gjort endringene, og til og med jobbe med flere sett med endringer samtidig ved å bruke grener. Som et resultat blir ikke arbeidet overskrevet, og eventuelle konflikter mellom filer er tydelig fremhevet.

Hvis du ikke har jobbet med Git før, vær ikke redd: vi har skrevet både en introduksjon til Git samt et innlegg om mer avanserte Git-arbeidsflyter.

Å lese:  Spyl deg ned, det er de hotteste WordPress-tweetene i juli 2024

Bestemme hva du skal spore

Når vi flytter nettstedet vårt under versjonskontroll, hva vi ikke gjør det holde styr på er nesten like viktig som det vi gjør:

Generelt sett, versjonskontroll er for sporing av kildekode, ikke eiendeler generert av verktøy eller prosesser. Dette inkluderer ting som sammenkoblet/minifisert CSS og JavaScript, eksterne avhengigheter osv. Samlet refererer vi til disse elementene som gjenstander.

For eksempel, hvis du bruker en CSS-forprosessor som Sassskal de genererte CSS-filene ikke spores under versjonskontroll. Ikke bare er de lett reproduserbare, de er vanskelige å lese og en vanlig kilde til flettekonflikter når flere utviklere er involvert.

Når det gjelder avhengigheter (biblioteker, WordPress-plugins, etc.), dra nytte av verktøy som Komponist og WPackagist i stedet for å samle kode som du ikke er ansvarlig for i depotet ditt.

I tillegg skal et Git-lager aldri inneholde ting som passord, private SSH-nøkler eller annen konfidensiell informasjon som vil bli vurdert hemmeligheterettersom alle utviklere med en kopi av depotet da vil ha den sensitive informasjonen på datamaskinene sine.

Strukturering av depotet ditt

Når du setter opp et Git-depot for et WordPress- eller WooCommerce-nettsted, er det generelt best å behandle wp-content/ som roten til depotet, siden du vanligvis ikke vil berøre filer over denne katalogen.

Plugins og temaer som nettstedet ditt bruker, men du ikke vedlikeholder koden for, bør deretter lastes inn via Composer, siden de er eksterne avhengigheter. På samme måte bør behandlede CSS- og JavaScript-filer ekskluderes via .gitignore-filen, siden disse artefaktene vil bli bygget for oss som en del av utgivelsesprosessen vår.

Vi har en gratis depotmal tilgjengelig på GitHub for å komme i gang.

En introduksjon til CI/CD

Når det gjelder distribusjon av programvare, er det to viktige begreper å forstå: Kontinuerlig integrering (CI) og Kontinuerlig levering (CD).

Disse to begrepene er nært beslektet, så mye at de ofte omtales samlet som “CI/CD”, og banen som endringene våre flyter gjennom blir dermed “CI/CD-rørledningen”. Denne rørledningen har vanligvis følgende form:

  1. Bygg utgivelsen: installer avhengigheter (Composer, npm, etc.), bygg deretter artefakter (Webpack, Grunt, Sass, etc.)
  2. Test konstruksjonen: kjør enhetstester, sjekk kodestandarder, utfør statisk kodeanalyse, etc.
  3. Distribuer utgivelsen til ett eller flere miljøer
Å lese:  4 måter Emojis kan blåse liv i markedsføringsstrategiene dine på

Kontinuerlig integrering er prosessen med å kontinuerlig teste koden vår for å sikre at endringer ikke bryter eksisterende funksjonalitet, slik at våre nye endringer ryddig med den eksisterende kodebasen. Hver gang nye endringer blir presset, kjøres det kontroller for å sikre at vi ikke “bryter bygget”.

For at kontinuerlig integrasjon skal være nyttig, sjekker disse være automatisert. For eksempel, hvis du har en pakke med enhetstester, kan du velge å kjøre denne testpakken hver gang en ny pull-forespørsel åpnes, og varsle deg om mulige bruddkode lander i produksjon.

Kontinuerlig integrasjon er imidlertid ikke begrenset til enhetstester, siden det finnes en rekke “kodefrie” kontroller som kan kjøres automatisk mot koden din, inkludert:

Å kjøre disse sjekkene automatisk ved hvert trykk sikrer også at all kode kjøres gjennom de samme sjekkene, og forhindrer at kode som ikke passerer blir frigitt.

Kontinuerlig levering, på den annen side, er ideen om at vi skal kunne “levere” (distribuere) koden vår til enhver tid. For å oppnå dette, må vi ha en skriptet distribusjonsprosess som, med et klikk på en knapp, sømløst vil flytte koden vår til produksjon.

Å ha distribusjonene skriptet betyr at du kan distribuere begge deler jevnlig og konsekvent; hver distribusjon fungerer på samme måte som den før den. Som et resultat kan teamet ditt distribuere mer regelmessig med et høyere nivå av selvtillit og færre bekymringer om at noen har gått glipp av et skritt på veien. For noen lag er det ikke uvanlig å distribuere dusinvis (eller til og med hundrevis) ganger om dagen!

Å lese:  Nybegynnerveiledning til studiobelysning for produktfotografering

Avhengig av nettstedet ditt, vil du kanskje til og med se på “den andre CDen”, Kontinuerlig distribusjon; det er veldig likt kontinuerlig levering, men under denne modellen blir hvert trykk til en gren distribuert automatisk. Dette kan være ekstremt kraftig når du bruker et forgrenet versjonskontrollskjema (slik som Github Flow), men kan være uønsket hvis du trenger å planlegge utgivelsesvinduer eller utføre alt arbeid i hovedgrenen.

Distribuere et WordPress- eller WooCommerce-nettsted med CI/CD

Nå som vi har en forståelse av den grunnleggende terminologien, la oss ta en titt på distribusjon av et typisk WordPress- eller WooCommerce-nettsted:

For denne øvelsen skal vi bruke grenet CI/CD-verktøy designet rundt behovene til WordPress-utviklere fra de samme folkene bak WP pusher. Best av alt, Branch har innebygd støtte for distribusjon til Hostinger!

For å komme i gang, registrer deg for Branch ved å koble til GitHub-, GitLab- eller Bitbucket-kontoen dinog deretter opprette ditt første nettsted.

Deretter vil vi konfigurere alle trinnene som er nødvendige for å bygge nettstedet vårt. Branch tilbyr en rekke “oppskrifter” for vanlige handlinger (installere Composer-avhengigheter, kjøre Webpack, etc.), men gir oss også muligheten til å legge til et hvilket som helst antall tilpassede trinn.

Når vi har skissert trinnene som er nødvendige for å bygge nettstedet vårt, kan vi gå videre til neste trinn i rørledningen vår: testing.

Hvis du allerede har en automatisert testpakke for nettstedet ditt, kan du ganske enkelt be Branch om å kjøre de kommandoene som er nødvendige. Selv om du ikke allerede har tester, Branch gjør det enkelt å legge til linting, kodestandarder og kompatibilitetskontroller.

Nå som vi har installert avhengighetene våre, bygget alt og bestått testene våre, er det på tide å få koden vår i produksjon!

Branch inneholder oppskrifter for distribusjon til Hostinger (så vel som andre store vertsleverandører), og koble de to plattformene er smertefritt:

  1. Velg nettstedet ditt i avdelingsoversikten, klikk på “Innstillinger”, og ta deretter tak i avdelingsnettstedets offentlige SSH-nøkkel
  2. Legg til denne offentlige nøkkelen til listen over nøkler i Hostinger-portalen
Å lese:  Hvordan øke hastigheten på sidens lastetid med enkle nettstedoptimaliseringer

Når Branch er i stand til å kommunisere med Hostinger-nettstedet ditt, kan vi velge «Hostinger»-distribusjonsoppskriften og fylle ut noen få detaljer:

  1. Vertsnavnet og brukernavnet for nettstedet (tilgjengelig via Hostinger-portalen på nettstedets “Access”-skjerm)
  2. Nettroten som vi distribuerer til. Hvis git-repoen vår er ment å fungere som wp-content/-katalogen, bør denne verdien være “public_html/wp-content”.
  3. Filene vi ønsker å distribuere (vanligvis er standard, “*”, tilstrekkelig)
  4. Git-grenen som skal distribueres til dette miljøet

“Git branch”-innstillingen er spesielt viktig, siden dette lar deg spesifisere forskjellige distribusjoner for forskjellige grener. For eksempel kan du ha en “staging”-gren som distribueres til scenemiljøet dittslik at du kan teste endringer før du gjør dem live.

Det er verdt å merke seg at Branch bruker kontinuerlig utplassering modell som standard, hvor rørledningen går med hvert trykk til den gitte grenen. Hvis du foretrekker mer av en kontinuerlig leveranse modell (hvor noen manuelle handlinger må iverksettes), kan du vurdere å opprettholde en “produksjons”-gren som først blir slått sammen når du er klar for utgivelse.

På dette tidspunktet bør Branch være konfigurert til å bygge og distribuere ditt git-lager til Hostinger! Du kan utløse din første distribusjon enten ved å klikke på “Run Deployment”-knappen på nettstedets “Pipelines”-side eller ved å trykke til Git-depotet ditt.

Tilpasse utgivelsesprosessen

En av de virkelig fine funksjonene til Branch er muligheten til å konfigurere flere trinn etter en vellykket distribusjon, for eksempel automatisk tømme nettstedets objektbuffer etter en distribusjon. Dette kan oppnås ved å bruke WP-CLI-oppskriften under “Annet”.

Verten og brukernavnet vil generelt være det samme som vi brukte i distribusjonstrinnet, og du kan lenke så mange kommandoer som nødvendig.

Konklusjon

Hvis du fortsatt sliter med cowboy-koding og/eller angstfylte utgivelser, ta en titt på gren og gjør utplasseringer til en lek!

Nye publikasjoner:

Anbefaling