Sådan foregår webudvikling i praksis
Udefra ligner udvikling en sort boks: du godkender designet, venter et par uger, en hjemmeside dukker op. At forstå hvad der sker indeni hjælper dig med at stille de rigtige spørgsmål og genkende advarselstegn tidligt.
Denne guide forklarer den praktiske gang, for den der bestiller frem for den der programmerer.
Miljøer: hvor arbejdet foregår#
Et seriøst projekt har mindst to miljøer, ofte tre. Er der kun ét, er det i sig selv et tegn.
| Miljø | Hvad det bruges til | Hvem har adgang |
|---|---|---|
| Lokalt | Udviklerens egen computer | Teamet |
| Test | Delt version til gennemgang | Team og kunde |
| Præproduktion | Kopi identisk med produktion | Teamet, før udrulning |
| Produktion | Den offentlige side | Alle |
Ændringer direkte i produktion er den hyppigste kilde til uventede nedbrud. Får du at vide, at der ikke er et testmiljø, så spørg hvorfor.
Arbejdscyklussen#
De fleste teams arbejder i korte cyklusser, med noget der kan gennemgås i slutningen af hver.
- Arbejdet deles i små opgaver, hver med et kontrollerbart resultat.
- Hver opgave udvikles separat, med versionsstyring.
- En anden gennemgår koden før sammenfletning, når teamet har størrelse til det.
- Resultatet ryger til testmiljøet, hvor det kan ses.
- Du gennemgår og giver konkret feedback, med adresse og skærmbillede.
- Rettelser går ind i næste cyklus, medmindre de blokerer.
- Hver eller hver anden uge er der en version at gennemgå, ikke først til sidst.
Et projekt, hvor du først ser resultatet til sidst, er et risikoprojekt. Bed om adgang til testmiljøet fra første uge.
Test før udrulning#
Hvad der bør være kontrolleret før hver udrulning, uanset projektstørrelse.
- Funktion: hver formular, hvert forløb, hver knap der gør noget.
- Browsere: dem dine besøgende faktisk bruger, ifølge analytics.
- Enheder: rigtige mobiler, inklusive en gammel og langsom.
- Ydeevne: målt, ikke skønnet, på hovedskabelonerne.
- Tilgængelighed: tastatur, kontrast, etiketter, overskriftsstruktur.
- Indhold: ingen pladsholdertekst, ingen links til testdomænet.
- Regression: det der virkede, virker stadig.
- Sikkerhed: validering af input, rettigheder, HTTPS.
Udrulning og tilbagerulning#
Udrulning skal være rutine og kedelig. Er det en anspændt begivenhed, er det tegn på en skrøbelig proces.
| Praksis | Hvorfor det betyder noget |
|---|---|
| Automatiseret udrulning | Fjerner glemte manuelle trin |
| Tilbagerulning på minutter | Gør en alvorlig fejl til en lille hændelse |
| Backup før udrulning | Sikkerhedsnet for databasen |
| Versionsstyrede datamigreringer | Reproducerbare databaseændringer |
| Verifikation efter udrulning | Fanger det der kun fejler i produktion |
| Udrul på et roligt tidspunkt | Færre berørte brugere, mere opmærksomhed |
| Log over udrulninger | Gør det muligt at koble problemer til ændringer |
Spørg hvor lang tid en tilbagerulning tager. Er svaret «det kommer an på» eller «vi har aldrig haft brug for det», findes der ingen tilbagerulningsplan.
Ofte stillede spørgsmål
Hvor ofte skal jeg se fremdrift?
Hver eller hver anden uge, med noget synligt i testmiljøet. Længere cyklusser øger risikoen for sent at opdage en misforståelse. Meget korte cyklusser med konstant feedback har også en pris, fordi afbrudt arbejde er ineffektivt. En takt på hver anden uge fungerer godt i de fleste projekter.
Hvad gør jeg, hvis projektet bliver forsinket?
Find først årsagen: manglende indhold, voksende omfang eller optimistisk estimat. De tre løses forskelligt, og den første ligger ofte på kundesiden. Vælg derefter mellem at skære i omfanget eller flytte datoen — at tilføje folk midt i et forsinket projekt forsinker det som regel yderligere.
Skal jeg kunne kode for at styre det her?
Nej. Du skal vide, hvilke spørgsmål du skal stille: er der et testmiljø, hvordan udrulles der, hvor lang tid tager en tilbagerulning, hvad er testet, hvem har adgang til koden. Svarene siger meget om processens soliditet, uden at du læser en linje kode.
Hvad er versionsstyring, og hvorfor betyder det noget?
Det er systemet — næsten altid Git — der gemmer historikken over alle kodeændringer og gør det muligt at gå tilbage. Det betyder noget af tre grunde: det gør det muligt at rulle en fejl tilbage, det lader flere arbejde parallelt, og det er beviset på at koden er din og kan overdrages. Et projekt uden versionsstyring er et projekt uden historik.
hvordan webudvikling foregårtestmiljøversionsstyringudrulle hjemmesideudviklingsprocesstyre webprojekt
