Hvordan jeg arbejder og best practices
I løbet af årene har jeg etableret et vist workflow og best practices, delvist overtaget fra TYPO3 communitien og delvist skabt baseret på erfaringerne med forskellige bureauer, jeg arbejdede med.
De værktøjer og principper, jeg bruger, inkluderer bl.a. git, composer, DDEV, frontend prototyping og automatiserede deployments.
Versionskontrolsystem (git)
En af de centrale brikker er brugen af et versionskontrolsystem, helst git. Jeg er bekendt med både GitLab med GitLab CI og GitHub med GitHub Actions. Jeg foretrækker personligt GitHub på grund af deres interface og efter min mening lidt bedre continuous integration modul (GitHub Actions). Hvis jeg skal styre repositoriet eller introducere git, fordi bureauet ikke har noget versionskontrolsystem, bruger jeg GitHub over GitLab. Dette punkt er ikke til forhandling. Hvis du ikke allerede bruger git, og du ikke er villig til at introducere det i din daglige arbejdsrutine, er vi ikke skabt til hinanden. Et versionskontrolsystem gør bare arbejdet med softwareprojekter så meget nemmere og løfter dit projekt og dit arbejde til et mere professionelt niveau.
Frontend prototype
Til nye projekter, hvor jeg er ansvarlig for frontend-delen, bygger jeg altid en frontend-prototype inklusiv et defineret build-workflow efter atomic design principper. Frontend-prototypen gør det nemt at skabe visse varianter af elementer og scenarier som f.eks. fejl situationer, når brugerinteraktion er involveret. Disse scenarier og varianter er nogle gange svære at skabe i den egentlige applikation.
Composer
Til selve TYPO3 CMS'et bruger jeg altid den composer-baserede installationsmetode. Dette anbefales af TYPO3-communitien, giver mulighed for fin kontrol over de installerede pakker, gør det let at administrere afhængigheder og muliggør strømlinede opdateringsprocedurer og automatiske tjeks for opdateringer. Ligesom versionskontrolsystemet er dette ikke til forhandling.
DDEV / Lokalt udviklingsmiljø
Når jeg arbejder på et TYPO3-projekt, bruger jeg altid en lokal kopi af projektet/websitet. Det giver mig mulighed for at foretage ændringer hurtigt, brug af det rette værktøjer på min maskine og - meget vigtigt - giver mulighed for at bruge en debugger (XDebug) til at finde ud af, hvad der sker og hvorfor.
Staging / testing miljø
Afhængigt af projektets størrelse og krav bruger jeg et eller to ekstra miljøer/kopier af websitet.
Jeg bruger næsten altid et såkaldt staging miljø. Dette kaldes nogle gange test- eller QA-miljø. Dette bruges til at give kunden en forhåndsvisning af nye funktioner. Det er også stedet, hvor kunden skal teste ændringer eller nye funktioner, der for nylig blev implementeret. Det kan også fungere som legeplads for kunden. Staging-miljøet afspejler normalt de seneste kodeændringer og nye funktioner, uanset om de er klar til produktion eller ej.
Hvis projektet kræver det, bruges et separat dev- eller preview-miljø. Dev-miljøet afspejler den seneste kode og bruges normalt til interne testformål. Kunden kan selvfølgelig have adgang til dev-rmiljøet til testformål. Hvis der findes et dev-miljø, kan staging-miljøet bruges om en præ-release-miljø. I dette tilfælde indeholder staging-miljøet ikke længere den seneste kode, men kun de ændringer, der er erklæret klar til produktion enten efter intern test eller kundetest.
Hvilke miljøer der bruges og til hvilke formål kan påvirke branching-strategien. Læs venligst mere om, hvordan jeg bruger git branches i et TYPO3-projekt.
Automatiseret deployment
En af de største fejlkilder i et softwareprojekt er de mennesker, der bygger det. Det er derfor, jeg foretrækker at automatisere så meget som muligt, især kritiske dele som hvordan websitet overføres til serveren.
Jeg bruger et continuous integration/continuous delivery workflow til at automatisere build og deployment af nye versioner af et projekt. Jeg er bekendt med både GitLab CI og GitHub Actions (jeg foretrækker dog GitHub Actions). Projektets resources og pakker bygges så meget parallelt som muligt ved hjælp af frontend build-processerne og composer. Derefter lægges alt sammen og bliver lagt ud på serveren. Under deployment'et udføres forskellige nødvendige opgaver. Dette kan være opdateringer til databaseskemaet, kørsel af opgraderingsprocedurer til migrering af data eller opdatering af sprogpakkerne.