Project Guardrails: Provisioning Environments

Den här serien med korta artiklar består av några saker jag har lärt mig under de senaste åren av att driva projekt baserade i det område där vi (förutsatt att du läser det här kommer från samma del av branschen som jag gör 🙂) arbete.

Om du bara snubblar över detta, täcker serien några faktorer som är viktiga för ett projekt :

1. Det bör inte finnas någon " design av kommitté”. "
2. Ingen annan som kärnutvecklingsteamet ska kunna tillhandahålla utveckling, iscensättning och produktion.
3. Ingen ska kunna skriva till produktionen förutom utvecklingsteamet (och även då borde det finnas en distributionsprocess).

Jag gillar inte riktigt att göra hårda och snabba regler som denna, nämligen för att saker och ting förändras med tiden antingen av nödvändighet eller av mer erfarenhet. Det är därför jag gillar "riktlinjer".

Men när detta skrivs är det de här sakerna jag ser utspela sig.

Provisionsmiljöer

Under de senaste åren har vi gjort stora framsteg när det gäller hur snabbt vi kan tillhandahålla våra system så att de alla speglar varandra (eller i allmänhet så). Detta inkluderar våra utvecklingsboxar, hur våra lokala maskiner speglar iscensättning och hur iscensättning speglar produktionen.

Att tillhandahålla en ny miljö, mer eller mindre. Spela med.

Det är om det "fungerar på min maskin" borde faktiskt vara sant. Inte en ursäkt för att inte kunna reproducera en bugg.

Och när det är sant, är det sannolikt sant på andras maskiner, på iscensättning och produktion. Och det här är trevligt, eller hur? Jag menar, vi snurrar upp våra lådor, distribuerar våra skript eller gör vad vi gör och sedan har vi den inställning vi behöver.

Så vad innebär det att ta hand om provisioneringsmiljöer? Det beror på vilken miljö du syftar på.

Hur ser det här ut egentligen?

Om du arbetar i WordPress, vilket jag antar att du är om du läser detta, så förutsätter det att du kör en webbserver, en databas och åtminstone PHP.

En utvecklingsmiljö kan se ut så här:

• Apache of Nginx ,
• MySQL som är det vanligaste,
• Minst PHP 5.2.4 (med PHP 7.1 rekommenderad),
• Eller något jämförbart.

Du kanske också använder något som Laravel Valet eller något som VVV. Allt beror på arten av ditt arbete.

Beroende på din verksamhets karaktär kan du dessutom ha en IDE som är tilldelad dig tillsammans med olika konfigurationsfiler för att upprätthålla vissa regler.

Och resten av miljöerna?

Som vanligt:

• utveckling avser installationen på din lokala dator,
• iscensättning avser det område där du och intressenterna kan testa,
• och produktionen är där applikationen finns.

Men det här ser också olika ut beroende på var du arbetar, hur ditt arbete är organiserat osv. Det handlar inte så mycket om hur det används – det handlar om att det används.

Iscensättning

Detta kommer vanligtvis att tillhandahållas på en server (eller grupp av servrar beroende på projektets storlek) till vilken du kan distribuera din senaste kod för testning. Den kan inkludera partiell funktionalitet, testdata och endast en delmängd av information från produktionen (om du väljer att hämta den informationen, nämligen databasen, från produktionsmiljön).

Detta ger dig och de andra intressenterna möjligheten att se över vad som händer och hur det kommer att fungera i produktionen utan att egentligen behöva oroa dig för att förstöra något känsligt.

Koden distribueras vanligtvis från en gren, vanligtvis master, från ditt Git-förråd (om det är det du använder). Och verktyg som DeployBot, CircleCI, Travis CI, GrumPHP, Behat, etc. används också för att både utvärdera kodkvaliteten, köra eventuella automatiserade tester och sedan slutligen distribuera koden.

I slutändan kommer varje miljö att tillhandahållas på ett sätt så att de snabbt kan speglas över lokala maskiner, mellanlagringsservrarna och produktionsservrarna. Vidare bör det vara lätt att skjuta och dra data mellan dem för att göra det enkelt att arbeta med datan.

Produktion

Slutligen handlar produktionen om det faktiska fungerande projektet; Detta innebär att servern, applikationen och databasen körs tillsammans med varandra och används av användare.

Detta betyder också att koden är på en stabil plats. Det finns sannolikt loggningsmekanismer på plats som kommer att meddela utvecklingsteamet om eventuella problem. Ingen ändring av koden bör ske i den här miljön utan att den har klarat QA eller iscensättning först.

Och processerna på plats?

Okej, så låt oss säga att du arbetar med en traditionell installation, i brist på en bättre term, där alla dina distributioner görs via S/FTP till en produktionsmiljö (eller till och med iscensättning). På så sätt kan användare dra ner filer, göra ändringarna och trycka upp dem igen.

Det är inte bra.

Detta innebär att alla med referenserna kan logga in, göra ändringarna och kringgå källkontroll, kontinuerlig integration, kvalitetssäkringsverktyg och så vidare, utföra vilka ändringar de vill.

Det undergräver hela de processer som införts. Detta går inte bara förbi standardproceduren (som är på plats av en anledning, förstås), utan det slutar med att den bryter koden som en utvecklare eller ett team av utvecklare har på sina maskiner, främst för att det som är i produktion inte längre är synkroniserat med kodens arkiv.

Dessutom kan denna kod spridas över grenar som ännu inte ska slås samman eller distribueras. Detta lämnar oss med en mängd olika situationer där utvecklare och kunder har brutit någon del av byggprocessen och därmed hela projektet.

När det är dags att kontrollera produktionen är den inte synkroniserad med utveckling och iscensättning, och ingen vet varför. När det är dags att implementera skrivs ändringarna över och de ansvariga har förlorat det de trodde att de skulle se.

Vad ska ett team göra?

Jag vet inte om det finns ett rätt svar på detta, men ju längre jag jobbar i den här branschen, desto mer tror jag att företaget – eller företagen – som ansvarar för att bygga lösningen åt kunden bör ha kontroll över processen från slutet. att sluta.

• Designers ansvarar för att hantera sina områden för att skapa koncept, håna, skapa demomallar och be om feedback,
• Projektledare ansvarar för att kommunicera med avdelningar,
• Utvecklare ansvarar för att implementera lösningen och knyta samman designernas arbete med den funktionella back-end,
• Kunden ansvarar för att granska ändringar, ge feedback och tillhandahålla all annan information som behövs för att slutföra uppgiften.

Detta betyder att när det kommer till att sätta upp domänen så faller hosting, miljöer, versionskontroll, byggprocessen och kontinuerlig integration och allt annat som jag har försummat att nämna helt och hållet på utvecklingsteamet.

Stanna i skyttegravarna, håll dig på målet (men var uppmärksam på dem runt omkring dig).

Enkelt uttryckt är detta inte kundens ansvar och borde inte vara det. Ansvarsgränser bör sättas, underhållas och respekteras i alla team – inte bara utvecklare och kunder eller kunder och designers eller designers och utvecklare och så vidare.

Vad kommer härnäst?

I nästa inlägg kommer jag att prata om det ansvar som utvecklare (och andra intressenter) har för att underhålla miljöer för koden.

Det vill säga vem som ska ansvara för vad och vem som har tillgång att läsa och skriva vilken data och hur det i slutändan kan påverka resultatet av projektet.