Slik foregår webutvikling i praksis
Utenfra ligner utvikling en svart boks: du godkjenner designet, venter noen uker, en nettside dukker opp. Å forstå hva som skjer inni hjelper deg å stille de riktige spørsmålene og gjenkjenne varselsignaler tidlig.
Denne guiden forklarer den praktiske gangen, for den som bestiller snarere enn den som programmerer.
Miljøer: hvor arbeidet foregår#
Et seriøst prosjekt har minst to miljøer, ofte tre. Er det bare ett, er det i seg selv et tegn.
| Miljø | Hva det brukes til | Hvem har tilgang |
|---|---|---|
| Lokalt | Utviklerens egen maskin | Teamet |
| Test | Delt versjon til gjennomgang | Team og kunde |
| Preproduksjon | Kopi identisk med produksjon | Teamet, før utrulling |
| Produksjon | Den offentlige siden | Alle |
Endringer direkte i produksjon er den vanligste kilden til uventede nedetider. Får du høre at det ikke finnes et testmiljø, så spør hvorfor.
Arbeidssyklusen#
De fleste team arbeider i korte sykluser, med noe som kan gjennomgås på slutten av hver.
- Arbeidet deles i små oppgaver, hver med et kontrollerbart resultat.
- Hver oppgave utvikles separat, med versjonskontroll.
- En annen gjennomgår koden før sammenslåing, når teamet har størrelse til det.
- Resultatet går til testmiljøet, der det kan ses.
- Du gjennomgår og gir konkret tilbakemelding, med adresse og skjermbilde.
- Rettinger går inn i neste syklus, med mindre de blokkerer.
- Hver eller hver andre uke er det en versjon å gjennomgå, ikke først til slutt.
Et prosjekt der du først ser resultatet til slutt, er et risikoprosjekt. Be om tilgang til testmiljøet fra første uke.
Testing før utrulling#
Hva som bør være kontrollert før hver utrulling, uansett prosjektstørrelse.
- Funksjon: hvert skjema, hvert løp, hver knapp som gjør noe.
- Nettlesere: de dine besøkende faktisk bruker, ifølge analysen.
- Enheter: ekte mobiler, inkludert en gammel og treg.
- Ytelse: målt, ikke anslått, på hovedmalene.
- Tilgjengelighet: tastatur, kontrast, etiketter, overskriftsstruktur.
- Innhold: ingen plassholdertekst, ingen lenker til testdomenet.
- Regresjon: det som virket, virker fortsatt.
- Sikkerhet: validering av inndata, rettigheter, HTTPS.
Utrulling og tilbakerulling#
Utrulling skal være rutine og kjedelig. Er det en anspent hendelse, er det tegn på en skjør prosess.
| Praksis | Hvorfor det betyr noe |
|---|---|
| Automatisert utrulling | Fjerner glemte manuelle steg |
| Tilbakerulling på minutter | Gjør en alvorlig feil til en liten hendelse |
| Sikkerhetskopi før utrulling | Sikkerhetsnett for databasen |
| Versjonskontrollerte datamigreringer | Reproduserbare databaseendringer |
| Verifikasjon etter utrulling | Fanger det som kun feiler i produksjon |
| Rull ut på et rolig tidspunkt | Færre berørte brukere, mer oppmerksomhet |
| Logg over utrullinger | Gjør det mulig å koble problemer til endringer |
Spør hvor lang tid en tilbakerulling tar. Er svaret «det kommer an på» eller «vi har aldri trengt det», finnes det ingen tilbakerullingsplan.
Ofte stilte spørsmål
Hvor ofte skal jeg se fremdrift?
Hver eller hver andre uke, med noe synlig i testmiljøet. Lengre sykluser øker risikoen for sent å oppdage en misforståelse. Svært korte sykluser med konstant tilbakemelding har også en pris, fordi avbrutt arbeid er ineffektivt. En takt på hver andre uke fungerer godt i de fleste prosjekter.
Hva gjør jeg om prosjektet blir forsinket?
Finn først årsaken: manglende innhold, voksende omfang eller optimistisk estimat. De tre løses ulikt, og den første ligger ofte på kundesiden. Velg deretter mellom å kutte i omfanget eller flytte datoen — å legge til folk midt i et forsinket prosjekt forsinker det som regel ytterligere.
Må jeg kunne kode for å styre dette?
Nei. Du må vite hvilke spørsmål du skal stille: finnes det et testmiljø, hvordan rulles det ut, hvor lang tid tar en tilbakerulling, hva er testet, hvem har tilgang til koden. Svarene sier mye om prosessens soliditet uten at du leser en linje kode.
Hva er versjonskontroll, og hvorfor betyr det noe?
Det er systemet — nesten alltid Git — som lagrer historikken over alle kodeendringer og gjør det mulig å gå tilbake. Det betyr noe av tre grunner: det gjør det mulig å rulle tilbake en feil, det lar flere arbeide parallelt, og det er beviset på at koden er din og kan overdras. Et prosjekt uten versjonskontroll er et prosjekt uten historikk.
hvordan webutvikling foregårtestmiljøversjonskontrollrulle ut nettsideutviklingsprosessstyre nettprosjekt
