Share
I dag har WordPress 25% av alle verdens nettsteder, så det er trygt å si at det som startet som blogging programvare, har vokst til noe mye større enn sin ydmyke opprinnelse, og er klar til å bli brukt på produksjonsnivåer fra nyhetsportaler til fullfør webapplikasjoner.
Med dette nivået av profesjonalitet oppstår nye behov.
På en personlig blogg som leses av venner og familie, vil en ødelagt pluginoppdatering ikke forårsake mye mer enn liten irritasjon. Sannsynligvis vil leserne dine ikke engang se feilen. Når du arbeider foran hundretusenvis av besøkende, vil imidlertid en slik feil bli lagt merke til umiddelbart, og du vil ikke komme unna med det så lett.
"Det fungerte på min datamaskin" kan være sant, men det vil ikke gjøre den frustrerte kunden lykkeligere.
Derfor, ettersom du bygger et profesjonelt WordPress-nettsted for et større publikum, trenger du et hostingoppsett som hjelper deg med å sikre at oppdateringene dine er trygge og aldri ødelegger levemiljøet.
Så, hvordan ser du til at serveren din ikke vil bryte når du trykker på en ny oppdatering live, det være seg en ny versjon av temaet ditt eller en oppdatering til en eller flere av pluginene dine?
Ved å teste i et miljø som er identisk med live-serveren før du trykker på endringene dine, fortsetter du live.
Oppsettet starter med a utviklingsserver som du bruker til ditt daglige arbeid på produktet: utviklertesting, presentasjon av tidlige endringer til klienter og så videre. Denne serveren kan kjøre på datamaskinen eller en server i skyen.
Når du er fornøyd med hvordan ting ser på utviklingsserveren, i dette oppsettet, vil du ikke haste for å skyve koden din live. I stedet forplikter du endringene til versjonskontroll og distribuerer dem til en test server.
Fordi testmiljøet kjører serverprogramvaren som er identisk med programvaren på live-serveren, bortsett fra at den nye koden ikke er oppdatert til live-serveren enda, kan du bruke den til å oppdage eventuelle problemer som kan oppstå på serveren, men ikke på utviklingsmiljøet ditt. For å gjøre testingen enda mer realistisk og spotfeil forårsaket av data innført av kundene dine, kan du også fylle testdatabasen med ekte data fra din live server.
På testserveren sørger du for at alt fungerer som det skal ved å teste nettstedet manuelt eller ved å kjøre automatiserte tester, eller en kombinasjon av de to. Og først da, når testene er fullført, trykker du endringene live. Med tillit, vet du at endringene ikke vil ødelegge nettstedet ditt.
Selv om Dev-Test-Live-tilnærmingen er kjent blant programvareselskaper som bygger tjenester på nettet, har det tradisjonelt vært begrenset til utviklere og bedrifter med ressursene til å kjøre og administrere flere servere alene og for å holde dem synkronisert med samme server programvare og data.
Det betyr å betale for mange servere, men også mye vedlikeholdsarbeid.
På Pantheon kommer denne tilnærmingen til å bli bygget inn i tjenesten.
Pantheon er en skalerbar, rask WordPress og Drupal hosting service som ikke bare gjør det mulig for deg å teste koden din på en testserver før du trykker den live, men tvinger deg til å følge den beste praksisprosedyren i alle implementeringer.
I denne opplæringen lærer du hvordan du konfigurerer et WordPress-nettsted på Pantheon og utvikler og vedlikeholder det sikkert ved hjelp av Dev-Test-Live-arkitekturen og versjonskontrollen.
La oss komme i gang!
Nå som du vet hva vi skal bygge (og hvorfor), er det på tide å komme i gang.
En av de store tingene med Pantheon er prismodellen: Du betaler bare når nettstedet ditt går live, så du kan prøve alt og til og med demonstrere nettstedet ditt til venner og kunder før du må betale for kontoen din.
Først, gå over til Pantheon nettsiden og opprett din gratis konto.
Hvis arbeidet ditt består i å lage nettsteder for en mengde kunder, eller hvis du har et team av utviklere som jobber med deg, kan du registrere deg som et byrå. Byråer har samme prisstruktur, men får også ekstra funksjoner som Multidev, som gir deg mulighet til å gaffel et nettsted i flere utviklingsmiljøer for å lette samarbeidet og å bygge og demonstrere nye funksjoner uten å måtte oppdatere det primære miljøet.
Hvis du ikke er sikker på hvilken type konto som er riktig for deg, gå bare med standard en. Du kan alltid konvertere kontoen din til en agentkonto senere.
Når du er logget på, ser du følgende visning:
Klikk på Opprett nytt nettsted å begynne å bygge ditt første WordPress-nettsted på Pantheon.
På dette skjermbildet velger du et navn på nettstedet ditt på Pantheon: navnet brukes i Pantheon admin, og for å generere webadressene til miljøene dine. Du kan ikke endre dette navnet senere, så det er godt å gi det litt tanke, men ikke bekymre deg - det trenger ikke å være det samme som ditt WordPress-nettsteds siste navn.
Navnene er globale på tvers av Pantheon, så å velge noe veldig generisk kan føre til en feil. I så fall, prøv noe annet.
Etter å ha valgt navnet klikker du på Opprett nettsted.
Deretter blir du bedt om å velge startstatus for ditt nye nettsted. Du kan enten starte et nytt nettsted fra bunnen av eller importere et eksisterende Drupal- eller WordPress-nettsted:
Velge Start fra begynnelsen.
Under valget ser du en liste over forskjellige startpakker eller oppstrømmer, som de kalles på Pantheon.
Disse standard oppstrømmene vedlikeholdes av Pantheon, slik at når en ny oppdatering blir tilgjengelig for en som du bruker (WordPress, i vårt tilfelle), kan du enkelt oppdatere dem til nettstedet ditt via Pantheon Dashboard.
Når vi lager et WordPress-nettsted, klikker du på Installer WordPress.
Installasjonen begynner. Og etter en stund er den klar.
Klikk på Besøk Pantheon Dashboard knapp.
Nå har du et helt nytt WordPress-installasjon som kjører på en Pantheon-utviklingsserver og kan få tilgang til og styre den gjennom Pantheon Dashboard.
Øverst på skjermen ser du tre faner for de forskjellige servermiljøene: dev, Test, og Bo. Under hver kategori finner du en lignende menystruktur for å opprettholde den serveren og distribuere kode og data mellom miljøer:
Klikk på Nettstedadministrator knappen øverst til venstre på skjermen. Det vil lede deg gjennom din vanlige WordPress-installasjonsflyt:
Du kan også klikke på Besøk utviklingsstedet knappen for å vise nettstedet.
Nå som utviklingsmiljøet ditt er oppe, la oss ta en titt på de to andre miljøene.
Som vi så over, finner du på fanene for de tre servermiljøene på Pantheon-dashbordet: dev, Test, og Bo.
Hver av kategoriene representerer et av servermiljøene som kjører nettstedet ditt. dev er utviklingsmiljøet for testing når du jobber på nettstedet, og kanskje viser en tidlig versjon av nettstedet til kundene. Bo er versjonen av nettstedet som er i gang, og brukes av faktiske brukere.
I mellom er de to Test, miljøet som holder ditt nettsted relativt trygt fra dine feil. Før du kan trykke noe på Pantheon, må det alltid gå gjennom en Test miljø, slik at du får en siste sjanse til å sjekke at alt fungerer riktig før du sender koden din til naturen.
Da vi nettopp opprettet det nye WordPress-nettstedet, eksisterer det fortsatt bare i utviklingsmiljøet.
La oss lage et testmiljø for det.
Klikk på Test tab.
Siden dette er første gang på Test fanen, ser du litt informasjon om hvordan testmiljøet fungerer.
Klikk på Lag testmiljø å klone Dev-miljøet ditt for testing. På dette stadiet klones både koden og dataene fra Dev, da det ikke eksisterer et levende miljø ennå. I fremtidige oppdateringer, så vel snart, ser det imidlertid bare at kode flyttes fra Dev til Test. Det er fordi ideen er at på testserveren, vil du sjekke koden din mot data kopiert fra live-miljøet.
Testmiljøet er nå klart.
Klikk på Besøk teststedet for å kontrollere at teststedet ser ut akkurat som nettstedet som kjører på Dev-miljøet ditt. Du kan også klikke Nettstedadministrator å logge på WordPress dashboard. Bruk de samme admin-legitimasjonene du definerte for WordPress på Dev-serveren.
Du har opprettet en veldig enkel WordPress-installasjon med et utviklings- og testmiljø, og er klar til å begynne å tilpasse det.
Nå som du har et WordPress-installasjon som kjører i skyen, vil du sannsynligvis gjøre noe mer med det. I det minste vil du installere noen plugins og kanskje et tema, og tilpasse nettstedet slik at det passer deg. I et mer komplisert oppsett skriver du dine egne plugins og kan kanskje lage et tilpasset tema for å gjøre nettstedet ditt ditt eget.
Det er der vi kommer til hjertet i å jobbe med Dev-Test-Live-oppsett.
Oppsettet på Pantheon er basert på versjonskontroll: Pantheon holder hele WordPress-installasjonen, bortsett fra filopplastinger, som håndteres ved hjelp av et spesielt filsystem, i et Git-depot. På denne måten, når du distribuerer endringene til neste miljø, forblir alt alltid synkronisert, og du mister aldri endringene dine.
Det betyr også at den eneste måten å oppdatere Test- og Live-miljøene på, er via versjonskontroll. Du kan ikke installere plugins eller temaer på Live-serveren slik du sikkert er vant til når du arbeider med WordPress. Tross alt ville det bryte ideen om å teste oppsettet før du presset det live.
Så, hvordan installerer og oppdaterer du plugins og temaer på WordPress-siden din?
Du kan få tilgang til nettstedet ditt dev miljø på Pantheon på to måter: bruk av Git eller direkte over SFTP.
Mens du bruker Git, er det nyttig for noen mer avanserte brukstilfeller (vi tar en titt på det senere i opplæringen), en del av skjønnheten i Pantheon-oppsettet er at ved å bruke SFTP, kan du bruke Dev-miljøet som utviklingsserver . På denne måten er det mulig å hoppe over å ha en utviklingsserver som kjører på datamaskinen din i det hele tatt.
Valget er ikke permanent: du kan bytte mellom modusene avhengig av hva som fungerer best for oppgaven ved hånden.
Så, for øyeblikket, sørg for at Dev-miljøet ditt bruker SFTP Tilkoblingsmodus:
I SFTP-modusen gjør du endringene i WordPress-installasjonens kodebase direkte på serveren, og når alt ser bra ut, gjør du endringene til Git ved hjelp av verktøyene på Pantheon-dashbordet.
På denne måten kan du bruke Dev-siden som du vil bruke et hvilket som helst WordPress-nettsted og tilpasse nettstedet ved å bruke WordPress-dashbordet akkurat som du ville på en enkelt serveroppsett.
La oss prøve det i aksjon.
I WordPress-administrasjonspanelet velger du plugins > Legg til ny. Deretter velger du et plugin du vil installere. Som et eksempel installerte jeg JetPack av WordPress.com:
Aktiver nå pluginet og kontroller at det kjører som forventet på Dev-serveren din.
Når du er fornøyd med plugin, gå tilbake til Pantheon Dashboard. Der ser du at systemet har lagt merke til endringene og viser dem som endringer som er klare til å bli presset til versjonskontroll.
Klikk på tekstfeltet som sier Legg til en commit-melding for å legge inn meldingsmeldingen din og for å se litt mer om endringene som skal gå til versjonskontroll.
Kontroller endringene, legg til en beskrivende meldingsmelding, og klikk Begå å forplikte endringene.
Når forplikten er ferdig, er endringene tilgjengelige for å bli distribuert til Test-serveren. For å gjøre dette, klikk på Test tab.
Der ser du følgende varsel.
Det er den forpliktelsen du bare gjorde på din dev miljø, nå klar til å bli distribuert til Test.
Skriv inn en beskrivende loggmelding og klikk på Distribuere kode fra utvikling til testmiljø.
Deretter besøker teststedets WordPress Dashboard for å sjekke endringene.
På plugins siden, ser du at pluginet er installert, men det er ikke aktivt ennå.
Det er fordi på Pantheon, mens koden blir oppdatert fra Dev opp mot live-serveren, endres databaseendringer, inkludert informasjon om de aktive pluginene, strømmen den andre veien, fra Live mot Dev.
Fordi plugins ofte kjører noen kode ved aktivering, for plugins, er dette ikke dårlig. Du trenger bare å huske å aktivere pluginene etter at distribusjonen er fullført, og du er klar til å gå. I min neste Pantheon-veiledning vil jeg vise hvordan du kan automatisere dette ved hjelp av Pantheons kommandolinjeverktøy.
Men mens denne tilnærmingen fungerer for plugins, er det andre data, for eksempel plugin og temainnstillinger, som utgjør en viktig del av nettstedets oppsett som du sannsynligvis ikke vil konfigurere manuelt etter distribusjonen..
La oss se på hvordan du kan sende dem fra ett miljø til det neste.
Som vi husker, løper kode- eller filer i versjonskontroll fra utviklingsmiljøet til live-serveren. Så, for å flytte innstillinger på lignende måte, er den mest naturlige tilnærmingen å lagre dem i versjonskontroll.
For å gjøre dette, vil vi bruke et gratis WordPress-plugin som bare gjør det.
Plugin, WP-CFM, leser alternativer fra WordPress-tilleggstabellene og lagrer dem i en tekstfil, som deretter kan være forpliktet til versjonskontroll (husk, hele WordPress-installasjonen, unntatt opplastingsmappen, lagres i versjonskontroll og leses i de andre miljøene).
La oss gjøre dette neste.
Følg instruksjonene fra trinn 2 over for å installere WP-CFM-pluginet i Dev-miljøet og distribuere det til Test. Aktiver deretter pluginet i begge miljøer.
Nå som plugin er aktiv i begge miljøer, kan vi bruke den til å trykke WordPress-alternativer fra Dev to Test. Hvis du vil, kan du endre noen WordPress-innstillinger på dette tidspunktet, slik at du får se hvordan endringene blir brukt på Test-serveren (nettstedets navn er for eksempel en ganske synlig endring).
I Dev-serverens WordPress dashboard klikker du på innstillinger > WP-CFM.
Klikk Legg til pakke å opprette en ny innstillingspakke for versjonskontroll. Bunter er samlinger av innstilling som kan lagres og skyves uavhengig av hverandre.
Deretter blir du bedt om å velge alternativene du vil inkludere i bunten. Hvis du vil beholde noen alternativer som er forskjellige fra ett miljø til det neste, kan du fjerne merket i listen.
I eksemplet ovenfor valgte jeg alt i WP-alternativer, bortsett fra listen over aktive pluginprogrammer (fordi jeg vil kunne kjøre pluginaktiveringsskriptene på alle miljøer), men du kan velge hva som er logisk med nettstedet ditt.
Når du er fornøyd med listen over alternativer, klikker du Lagre endringer.
Når du har lagret bunten, vil du se nye knapper for den:
Klikk på diff knappen for å se forskjellene mellom Dev-databasen og innholdet i alternativfilen som eksporteres av WP-CFM.
Siden WP-CFM ikke har opprettet en eksportfil, vil diffen vise alt som lagt til:
Lukk Diff-popup-vinduet, og klikk Trykk å lagre dataene fra databasen til eksportfilen.
Nå, når du går tilbake til ditt Pantheon dashboard dev fanen, ser du at WP-CFM har opprettet en JSON-fil (wp-innhold / konfig / site_options.json) klar til å være forpliktet til versjonskontroll:
Forbind endringene og distribuere dem til Test miljø.
Deretter navigerer du til Test-serverens WordPress dashboard innstillinger > WP-CFM.
Først vil du legge merke til at Nettstedvalg Bunt er nå tilgjengelig også i dette miljøet.
På grunn av begrensningene som er satt til test- og levende miljøer, vil du imidlertid også merke at alternativpakken bare virker i en retning: wp-innhold / konfig kan ikke skrives på testmiljøet. Dette er bra fordi det vil hjelpe oss med å holde eksportfilen ren.
Klikk på Dra knappen for å lese innholdet i konfigurasjonsfilen og bruke dem i din WP-alternativer bord. I bekreftelsesmenyen som spør "Import filinnstillinger til DB?", Svar OK.
Nå, hvis du har gjort noen endringer i WordPress-alternativene dine før du gjør Push på Dev-serveren, bør du se disse endringene også brukt på teststedet.
På et tidspunkt i ditt livs livssyklus vil du kanskje ta de faktiske dataene fra din Live-server til Dev. Det kan være å teste en feil mot ekte data, eller bare for å se hvordan ting ser ut med ekte brukergenerert innhold i stedet for noen testdata laget av deg, utvikleren.
På dev miljø, klikk på Database / filer i menyen til venstre.
Her kan du velge miljøet for å klone dataene (test / live) og om du vil klone bare databasen eller også filopplastinger gjort i det miljøet.
Du har også muligheten til å oppdatere eventuelle nettadresser i databasen for å matche Dev-miljøets URL-struktur.
Legg merke til at kloning vil erstatte alt i Dev-miljøets database, så hvis du har tilpassede endringer som du vil ha tilbake etter kloning, bruk WP-CFM til å trykke dem inn i en tekstfil før du gjør kloning.
Denne funksjonaliteten er mest nyttig for å trekke data fra Live og Test to Dev, men du kan også bruke den til å klone Dev-databasen til Test (og til og med Live). Det kan for eksempel være nyttig hvis du lager ditt opprinnelige nettstedinnhold (sider og kanskje blogginnlegg) på Dev-miljøet og vil presse det til å teste på en gang før du oppretter Live-miljøet..
Vi har nå sett på de grunnleggende WordPress-administrasjonsoppgaver som installering av nye plugins og pushing konfigurasjonsendringer mellom miljøer.
Oppdatering av programtillegg og installering av temaer kan gjøres på samme måte, etter de samme instruksjonene. Så hvis du gjør alt ditt nettsteds ledelse ved hjelp av eksisterende temaer og plugins, er dette ganske mye det du trenger å vite om grunnlaget for Pantheon for å få det bra ut av det.
Ofte vil du imidlertid også endre koden selv, enten ved å skrive et plugin eller ved å endre og tilpasse et tema.
For å demonstrere hvordan du kan gjøre dette, la oss lage et enkelt barnemne for det gjeldende standardtemaet, tjue seksten, og trykk det helt til teststedet.
Fortsett å fortsette med tilgangen til å bruke Pantheon Dev-miljøet som utviklingsserver, la oss bruke din favoritt FTP-klient til å laste opp våre kodendringer på Dev-serveren.
Dette er enkelt, og vi har alle sannsynligvis gjort dette på en eller annen gang på andre servere på internett.
For å koble til Pantheon-serveren, først, på Pantheon Dashboard, klikk på STFP-tilkoblingsinfo knappen for å åpne en popup med informasjon om hvordan du kobler til utviklingsserveren.
Kopier Vert og Brukernavn informasjon til FTP-klienten og bruk Pantheon Dashboard-passordet for å koble til serveren. Pass på at du bruker Havn spesifisert i tilkoblingsinstruksjonene.
Når du er koblet til serveren, finner du WordPress-nettstedets hele kodebase i katalogen ~ / Code.
Når du er koblet til, kan du bruke FTP-klienten til å erstatte noen filer eller laste opp nye, og se endringene som brukes umiddelbart på Dev-serverens WordPress-side.
Mange FTP-klienter, kodeditorer og PHP IDEer (for eksempel PHPStorm og Eclipse) lar deg synkronisere kodendringene direkte med en ekstern server ved hjelp av SFTP. Ved å bruke disse verktøyene kan du gjøre utviklingen enda raskere med det ekstra trinnet for å laste opp endringene dine for testing som skjer automatisk i bakgrunnen.
Legg merke til at Dev-serverens SFTP-nettadresse kan endres fra tid til annen, så hvis du finner deg ikke i stand til å koble til, må du bare kontrollere nåværende tilkoblingsinformasjon fra oversikten og prøve igjen.
Som et eksempel på denne tilnærmingen, la oss lage et enkelt barn tema for standard temaet, tjue seksten. Da dette bare er for demonstrasjonsformål, holder vi temaet super enkelt med ingenting annet enn a style.css fil som endrer nettstedets bakgrunnsfarge til rød og a functions.php fil for enqueueing stilarket.
På datamaskinen din, opprett en katalog som heter twentysixteen-barn, og inne i det, en tekstfil som heter style.css.
Innsiden style.css legg til følgende innhold:
/ * Tema navn: Twenty Sixteen Barn Beskrivelse: Et enkelt barn tema Template: twentysixteen Versjon: 0.0.1 Lisens: GNU General Public License v2 eller nyere Lisens URI: http://www.gnu.org/licenses/gpl-2.0. html * / body background-color: # ff0000;
Deretter oppretter du en functions.php fil med følgende innhold:
Deretter laster du opp katalogen sammen med innholdet til Dev-serverens katalog ~ / Code / wp-content / themes /.
Nå, når du besøker Utseende > temaer skjerm på Dev-serverens WordPress-admin, ser du at det nye temaet nå er tilgjengelig for bruk.
Gå videre og aktiver den!
Nå, når du besøker Dev-nettstedet ditt, vil du legge merke til at bakgrunnen har blitt rød, akkurat som vi definerte i Child-temaets CSS-fil.
Du har nå lastet opp et nytt barntema til Dev-serveren din. For å sikre at du ikke mister endringene, og for å kunne distribuere den til Test-serveren, må du forplikte deg til versjonskontroll.
Når du utvikler nettstedet ditt direkte på Dev-miljøet ved hjelp av SFTP, er det viktig å huske at før du forplikter endringene til Git på Pantheon Dashboard, lagres de ikke i versjonskontroll. Så, for å sørge for at du ikke mister noen av dine viktige endringer, ikke glem å begå ofte - selv når du ikke er klar til å presse endringene dine til Test.
På Dev-miljøets Dashboard-fan vil du legge merke til at du har noen ubegrensede endringer klar til å bli forpliktet.
Skriv inn en commit-melding og klikk Begå.
I skjermbildet over, vil du også merke at det er endringer i site_options.json fil opprettet av WP-CFM. Det er fordi jeg presset informasjonen om å aktivere temaet til den konfigurasjonsfilen. På denne måten blir det nye temaet aktivert nesten automatisk. Selv om dette ikke er nødvendig i dette enkle eksempelet tilfelle, er det en god praksis å adoptere overveielse av fremtiden og mer komplekse temaoppsett du kan bygge.
Når du har begått endringene, distribuerer du dem til Test ved hjelp av trinnene som ble forklart tidligere da vi distribuerte plugininstallasjonene våre. Deretter, dersom du presset websitetsalternativerpakken ved hjelp av WP-CFM, bruker du pluginet til å trekke endringene til teststedets database.
Nå, når du besøker testmiljøets Utseende > temaer siden, bør du se det nye temaet som det aktive temaet.
Hvis du vil ha klarere kontroll over kodebasen og foretrekker å utføre utviklings- og utviklertesting på din lokale maskin, kan du skyve koden til Dev-serveren ved hjelp av Git-versjonen selv kontrollere i stedet for først å laste opp endringene til serveren over FTP.
For å gjøre dette, igjen på Dev-serveren Kode fanen, slå på Tilkoblingsmodus fra SFTP til Git.
Hvis du har noen ubegrensede endringer på Dev-serveren når du bytter til Git-modus, ser du en popup som ber deg om å bekrefte at du vil gjøre bryteren og miste endringene.
Hvis du vil beholde endringene, lukker du varslingen og begår før du fortsetter med å bytte modus. Hvis du ikke trenger endringene, skriver du inn SLETT i tekstfeltet og klikk på den store røde knappen.
Git-godkjenning på Pantheon er gjort ved hjelp av en SSH-nøkkel, så før du fortsetter videre, må du generere en nøkkel og legge den til i kontoen din. Du kan bruke samme SSH-nøkkel for alle dine Pantheon-nettsteder, så du trenger bare å gjøre dette en gang.
Med SSH-nøkkelen på plass, kan du begynne å jobbe med WordPress-installasjonen din ved hjelp av Git.
Klikk på Git Connection Info knappen på Dev-miljøet for å avsløre det nøyaktige git klon kommando å bruke til å trekke nettstedet ditt Git-depot til din lokale maskin.
Kjør git klon kommandoen på kommandolinjen, i en katalog der du vil lagre koden på datamaskinen din. Hvis du foretrekker å bruke et grafisk brukergrensesnitt, er det også bra: du kan fortsette og bruke din favoritt Git-klient.
Når du har klistret Git-depotet, ser du at katalogen inneholder hele WordPress-installasjonen.
For å teste å jobbe med Git, gjør en liten modifikasjon av barntemaet vi opprettet i de forrige trinnene.
Endre barnets tema style.css, endrer bakgrunnsfargen til grønn i stedet for rød. Deretter forplikter du endringen til git.
Skriv inn følgende kommandoer i prosjektmappen, på kommandolinjen:
$ git legg til wp-innhold / temaer / twentysixteen-child / style.css $ git commit -m "Endret barntemaets bakgrunnsfarge" $ git push origin master
Når push-kommandoen er fullført, besøk Pantheon Dashboard.
Der finner du endringen som er oppført i commit-loggen, og når du besøker nettstedet, ser du at bakgrunnen har blitt grønn.
Så, endringen du har gjort er nå til stede på Dev-serveren, men også klar til å bli distribuert til testmiljøet.
På en måte kan du bruke denne metoden til å enten omgå Dev-serveren helt (kjører utviklingen på din lokale maskin og bruker Pantheon for bare Test og Live-miljøer) eller som en annen måte for å laste opp kode til utviklingsserveren din.
Det er alt opp til deg og dine preferanser, så er valget mellom SFTP og Git selv.
Herfra er resten av arbeidsflyten, som distribuerer endringene dine til Test, og til slutt Live-den samme s
Accentsconagua