Share
I denne serien tar vi en titt på de ulike praksisene som brukes i profesjonell WordPress-utvikling. I den forrige artikkelen har vi gjennomgått et sett strategier og referansemateriale som er nyttige når du bygger temaer, plugins og WordPress-baserte applikasjoner.
I denne artikkelen tar vi en titt på versjonskontroll og miljøkonfigurasjoner som gjør det enkelt å utvikle, teste og distribuere arbeidet vårt for å minimere mengden feil som finner veien til siste versjoner av arbeidet vårt.
Dette emnet er ikke noe nytt. Faktisk vil jeg våge å si at flertallet av leserne her er kjent med Subversion og / eller Git (spesielt med GitHubs popularitet). Som sådan er poenget med denne artikkelen ikke så mye å gi en gjennomgang av de ulike kildekontrollsystemene eller å gjøre et tilfelle for hvilke du skal bruke, men det er ment å gjøre en sak for Hvorfor Du bør bruke kildekontroll og hvordan det er relatert til våre miljøer.
Hvis du er helt Ny til begrepet versjonskontroll, la oss gi en enkel definisjon av som vi kan jobbe for slik at vi alle er på samme side:
Versjonskontroll er et øyeblikksbilde av kildekoden din til enhver tid, slik at du kan tilbakestille når en feil er introdusert og arbeid på en ny funksjon uten å bryte eksisterende kode.
Innenfor WordPress-fellesskapet er folk ofte delt om å vurdere temaer og / eller pluginprogrammer eller glorifiserte nettsteder. Personlig tror jeg at de er en form for programvare som de er gjenstand for mange av de samme praksiser:
For det formål bør utvikling og vedlikehold av WordPress-spesifikk arbeid behandles som sådan, og det er industristandard for å gi et nivå av versjonskontroll på programvare.
I tillegg fungerer versjonskontroll hånd i hånd med å jobbe med prosjektet ditt, teste det og deretter distribuere det på en live server for at andre skal kunne bruke.
De fleste utviklere er kjent med de ulike miljøene, selv om de ikke bruker den nøyaktige terminologien. Enkelt definert:
Enkel nok.
Saken er at hvert av disse miljøene også er nært relatert til versjonskontroll på en slik måte at når du klarte det riktig, kan du minimere overhead for å opprettholde versjoner og distribusjon av arbeidet ditt.
Utviklingsmiljøet er den maskinen du faktisk utvikler prosjektet på. Den inneholder en kopi av WordPress, webserver, databaseserver, IDE og relaterte verktøy som du bruker til å bygge prosjektet.
Dette bestemte miljøet er hvor du skal gjøre hyppige forpliktelser. Ved dette mener jeg at hver gang du gjør en vesentlig endring - det være seg en ny funksjon, feiloppløsning eller noe lignende - da bør du forplikte kode til depotet.
Her er fordelen at du enkelt kan rulle tilbake, identifisere og skille mellom endringer hvis noe skulle gå galt under prosessen.
Når du har fullført en betydelig mengde endringer (hvor du eller teamet ditt bestemmer hva som betyr "signifikant"), er det på tide å markere settet av endringer og distribuere til scenemiljøet.
Staging Environment er en egen server som ligner på produksjonsmiljøet, men brukes til å teste prosjektet før det slippes ut. Den inneholder den nyeste versjonen av koden, testdata, og er ment for brukere å evaluere prosjektet før det slippes ut. Ingen utvikling bør skje her.
Selv om det ikke burde utvikles her, er det ikke uvanlig å ha ulike feilsøkingsverktøy på plass for å generere loggmeldinger eller vurdere hva som går inn i og kommer ut av databasen mens du arbeider på nettstedet.
Siden utviklere ofte begår et sett med endringer i depotet, må de testes. Dette er hvor scenemiljøet kommer til spill. Generelt sett svarer Staging Environment ofte til det siste settet av endringer var forpliktet til depotet.
Men dette reiser to spørsmål:
For det første er dette en god ting - det betyr at Staging Environment har tjent sitt formål! I tillegg gir det oss en sjanse til å se vår kildekode for å finne ut om en feil må løses eller en ny funksjon skal innføres.
Og dette er hvor kildekontrollen kommer til nytte.
Hvis en feil har oppstått, kan du lene seg i retning av å vende tilbake endringen, men i scenemiljøet som ikke er nødvendig. I stedet finner du bare hvor feilen er, løser den, legger til koden og omfordeler koden til scenemiljøet for testing.
Du gjentar denne prosessen til det ikke finnes noen feil eller, mer nøyaktig, kan du ikke finne noen feil.
Hvis du ikke klarer å finne noen feil, har du i hovedsak fått det som kalles en stabil bygg. På dette punktet kan du merke - eller stempel eller etikett, eller hvilken konvensjon ditt kildekontrollsystem tilbyr - en versjon av koden din og distribuere den til produksjonsmiljøet.
Selvfølgelig er det en sjanse for at en feil kan oppdages etter at den har blitt distribuert til produksjonsmiljøet. I så fall bør det tas spesielle tiltak.
Produksjonsmiljøet er synonymt med det levende nettstedet. Det er her de faktiske brukerne oppretter, administrerer og samhandler med faktiske data. Ingen utvikling bør skje her.
Det er veldig lite å snakke om produksjonsmiljøet når det gjelder utvikling. Tross alt, bør dette ikke være noe mer enn hvor kildekoden er distribuert for andre å bruke.
Men det er en sjanse for at det kan løses en feil her. Når dette skjer, dette er når en tilbakelevering skal skje. Enkelt sagt, en tilbakestilling er når du tar det siste settet av endringer og bokstavelig talt angre distribusjonen som gjenoppretter prosjektet i sin tidligere tilstand.
Før du foretar en tilbakestilling, er det verdt å merke noen rekreasjonstrinn, slik at du kan gjenskape det i både scenemiljøet og utviklingsmiljøet for å løse problemet riktig..
Herfra utfører du utviklingen som trengs for å løse problemet, forplikte seg til en annen endring, distribuere den til scenemiljøet, og distribuere den til produksjonsmiljøet forutsatt at den passerer testingen.
Tydeligvis dekker dette innlegget konsepter på et høyt nivå: Vi undersøker ikke hvilke versjonskontrollsystemer som er best, heller ikke ser vi hvilke verktøy som passer best for ditt operativsystem. Disse emnene er utenfor rammen av dette innlegget og er hver fortjener sin egen serie.
Men innenfor begrepet Professional WordPress Development kan disse rutinene åpenbart være nyttige i utvikling, testing og distribusjon av (og rullende tilbake) versjoner av prosjektet ditt.
I siste innlegg ser vi på noen av de ulike verktøyene som er tilgjengelige, som gjør det mulig for oss å diagnostisere mange feil i vårt lokale utviklingsmiljø med det formål å hindre at mange av dem selv når frem til scenemiljøet.
Accentsconagua