Share
I denna serie tittar vi på de olika metoder som används i professionell WordPress-utveckling. I den föregående artikeln har vi granskat en uppsättning strategier och referensmaterial som är användbara när du bygger teman, plugins och WordPress-baserade applikationer.
I den här artikeln tar vi en titt på versionskontroll och miljökonfigurationer som gör det enkelt att utveckla, testa och distribuera vårt arbete för att minimera antalet fel som leder till slutliga versioner av vårt arbete.
Det här ämnet är inget nytt. Faktum är att jag vågar säga att majoriteten av läsarna här är bekanta med Subversion och / eller Git (speciellt med GitHubs popularitet). Som sådan är punkten i den här artikeln inte så mycket att ge en rundtur i de olika källkontrollsystemen eller för att göra ett ärende för vilka du ska använda men det är tänkt att göra ett ärende för Varför du borde använda källkontroll och hur det är relaterat till våra miljöer.
Om du är fullständigt ny till begreppet versionskontroll, låt oss ge en enkel definition av vilken vi kan arbeta så att vi alla är på samma sida:
Version Control är en ögonblicksbild av din källkod vid vilken tid som helst som tillåter dig att rulla tillbaka när en bugg introduceras och arbeta på en ny funktion utan att bryta befintlig kod.
Inom WordPress-samhället är människor ofta delade på huruvida man inte bör överväga teman och / eller pluginprogram eller förtrollade webbplatser. Personligen tror jag att de är en form av programvara eftersom de är föremål för många av samma metoder:
För detta ändamål bör utveckling och underhåll av WordPress-specifikt arbete behandlas som sådan och det är industristandard att tillhandahålla en nivå av versionskontroll på programvara.
Dessutom fungerar versionskontroll hand i hand med att arbeta med ditt projekt, testa det och sedan distribuera det på en live-server för att andra ska kunna använda.
De flesta utvecklare är bekanta med de olika miljöerna även om de inte använder exakt terminologi. Enkelt definierad:
Enkelt nog.
Saken är att var och en av dessa miljöer också är nära besläktad med versionskontroll på ett sådant sätt att när du lyckas på rätt sätt kan du minimera kostnaderna för att behålla versioner och implementeringar av ditt arbete.
Utvecklingsmiljön är den maskin där du faktiskt utvecklar ditt projekt. Den innehåller en kopia av WordPress, webbservern, databasservern, IDE och relaterade verktyg som du använder för att bygga ditt projekt.
Denna speciella miljö är där du ska göra vanliga förbindelser. Med detta menar jag att varje gång du gör en betydande förändring - vare sig det är en ny funktion, buggupplösning eller något liknande - då bör du begå kod till förvaret.
Här är fördelen att du enkelt kan rulla tillbaka, identifiera och skilja mellan förändringar om något skulle gå fel under processen.
När du har slutfört en betydande mängd förändringar (där du eller ditt team bestämmer vad som är "betydande"), är det dags att markera uppsättningen förändringar och distribuera till scenmiljön.
Staging Environment är en separat server som liknar produktionsmiljön, men används för att testa projektet innan det släpps. Den innehåller den senaste versionen av koden, testdata och är avsedd för användarna att utvärdera projektet innan det släpps. Ingen utveckling bör ske här.
Även om ingen utveckling bör ske här är det inte ovanligt att ha olika felsökningsverktyg på plats för att generera loggmeddelanden eller granska vad som går in och kommer ut ur databasen medan du arbetar på webbplatsen.
Eftersom utvecklare ofta begår en uppsättning ändringar i förvaret måste de testas. Det är här scenen miljö spelar in. I allmänhet motsvarar scenmiljön ofta vad som än den senaste uppsättningen förändringar gjordes för förvaret.
Men detta väcker två frågor:
Först är det här en bra sak - det betyder att Staging Environment har tjänat sitt syfte! Dessutom ger vi oss en chans att granska vår källkod för att avgöra om ett fel måste lösas eller en ny funktion ska införas.
Och här är källkontrollen till nytta.
Om ett fel har uppstått kan du luta sig i riktning mot att rulla tillbaka ändringen, men i Staging Environment som inte är nödvändig. Istället identifierar du helt enkelt var felet är, löser det, begår koden och omfördelar sedan koden till scenmiljön för testning.
Du upprepar denna process tills inga fel uppstår eller, mer exakt, kan du inte hitta några buggar.
Om du inte kan hitta några buggar har du i huvudsak fått det som kallas en stabil byggnad. Vid denna tidpunkt kan du märka - eller stämpel eller etikett eller vilken konvention ditt källkontrollsystem erbjuder - en version av din kod och distribuera den till produktionsmiljön.
Naturligtvis finns det en chans att en bugg kan upptäckas efter att ha blivit utplacerad till produktionsmiljön. I så fall bör särskilda åtgärder vidtas.
Produktionsmiljön är synonym med den levande webbplatsen. Det är här de faktiska användarna skapar, hanterar och interagerar med faktiska data. Ingen utveckling bör ske här.
Det är väldigt lite att prata om produktionsmiljön vad gäller utveckling. Det borde inte vara något annat än vad källkoden används för att andra ska använda.
Men det finns en chans att en bugg skulle kunna släppas här. När detta händer, detta är när en rulla ska ske. Enkelt sagt, en återgång är när du tar den senaste uppsättningen förändringar och bokstavligen fördröjer implementeringen som återställer projektet till dess tidigare tillstånd.
Innan en rollback görs är det värt att notera några rekreationssteg så att du kan reproducera det i både scenmiljön och utvecklingsmiljön för att ordentligt lösa problemet.
Härifrån utför den utveckling som behövs för att lösa problemet, begå en annan förändring, använd den till scenariemiljön och sätt in den i produktionsmiljön förutsatt att den passerar testningen.
Självklart täcker den här posten koncept på hög nivå: Vi undersöker inte vilka versionsstyrningssystem som är bäst, och vi tittar inte på vilka verktyg som är bäst för ditt operativsystem. Dessa ämnen ligger utanför ramen för detta inlägg och är varje förtjänar av sin egen serie.
Men inom ramen för begreppet Professional WordPress Development kan dessa metoder uppenbarligen vara användbara vid utveckling, testning och implementering (och rulla tillbaka) versioner av ditt projekt.
I sista inlägget tar vi en titt på några av de olika verktyg som finns att tillgå som gör det möjligt för oss att diagnostisera många fel i vår lokala utvecklingsmiljö med syfte att förhindra att många av dem når till och med upp till Staging Environment.
Accentsconagua