Kort svar: Staging som standard betyder, at INGEN ændring rammer et kundesite direkte: alt bygges og testes på en staging-kopi, kunden godkender på en preview-adresse, og først derefter udrulles til produktion – med backup før og kontrol efter. Processen koster 10-15 minutter ekstra pr. opgave og fjerner de to dyreste ting i bureaulivet: nedbrud på kunders sites og diskussioner om, hvem der ødelagde hvad.
Forskellen på et bureau, kunderne stoler på, og et bureau, kunderne overvåger, er sjældent talentet – det er processen. Når kunden VED, at ændringer altid testes først og altid kan rulles tilbage, holder de op med at spørge „er det sikkert?“ og begynder at sige „bare gør det“. Denne artikel handler om at gøre staging til rygraden i jeres ændringsproces – selve teknikken (hvordan du opretter en staging-kopi) har vi dækket i staging-guiden.
1) Ændringen registreres – én sætning om hvad og hvorfor, i jeres opgavesystem, aldrig kun i en mail. 2) Frisk staging-kopi – klon produktionssitet NU (en uge gammel staging er en fælde: den tester fortiden). 3) Byg og test – gennemfør ændringen plus en fast minimumstest: forside, vigtigste formularer, checkout hvis det er en shop. 4) Kunden godkender på preview-adressen. 5) Udrul – med backup umiddelbart før, og efter-tjek umiddelbart efter. Skriv de fem trin ned som JERES standard, og lad dem gælde alle: også seniorudvikleren, også „den lille CSS-rettelse“. Processer, der har undtagelser for de erfarne, er ikke processer – de er anbefalinger.
Send kunden én mail: link til preview, to-tre linjer om hvad der er ændret, og en svarfrist („godkender du inden fredag, udruller vi mandag morgen“). Bed om godkendelse på SKRIFT – ikke fordi I ikke stoler på hinanden, men fordi „det havde jeg ikke godkendt“-samtalen aldrig må blive påstand mod påstand. Godkendelsen arkiveres på opgaven og gør månedsrapporten næsten selvskrivende: „gennemførte ændringer“ er bare listen af godkendte opgaver.
Udrul på faste tidspunkter – formiddage på hverdage, aldrig fredag eftermiddag – så der er folk på arbejde, hvis noget driller. Rækkefølgen: backup af produktion, udrulning (hele kloner ELLER ændringerne genskabt manuelt – vær opmærksom på, at en fuld overskrivning af databasen sletter ordrer og indlæg oprettet siden klonen på levende shops), og så efter-tjekket: samme minimumstest som på staging, plus et blik på fejlloggen. Først DEREFTER melder I „det er live“ til kunden. Går noget galt, er svaret aldrig panik-fejlretning på produktion: rul tilbage til backuppen, og tag problemet på staging, hvor det hører hjemme.
To ærlige undtagelser, så processen ikke bliver et dogme: Sikkerhedshastefix (aktivt angreb, kritisk sårbarhed) må gå direkte på produktion – med backup først og dokumentation bagefter; hastighed slår proces, når huset brænder. Rent indhold (tekstrettelser, nye indlæg, produktopdateringer) behøver ikke staging – det er reversibelt og rammer ikke koden. Grænsen går ved alt, der rører plugins, temaer, indstillinger eller struktur: DÉT skal på staging, uanset hvor lille det føles. Er I i tvivl, om noget er indhold eller teknik – så er det teknik.
Staging-processen er ikke kun risikostyring – den er et salgsargument. Skriv den ind i tilbud og driftsaftaler: „alle ændringer testes på en kopi af jeres site og godkendes af jer, før de går live“. Det er en sætning, kunder forstår og husker – og som de færreste konkurrenter kan matche med andet end „vi er forsigtige“. Forudsætningen er hosting, hvor staging er et klik og ikke et projekt: på Hostious’ bureau-hosting følger 1-klik staging med på alle sites, så processen aldrig strander på besværet.
Indførelsen behøver ikke et stort projekt: vælg processen til ALLE nye opgaver fra på mandag, og lad de igangværende køre færdige på den gamle måde. Efter en måned måler du: antal ændringer uden efterfølgende fejlrettelser, og hvor mange „det hastede“-undtagelser der sneg sig ind. Tallene plejer at overbevise de sidste skeptikere i teamet bedre end nogen politik – og giver dig samtidig sætningen til næste kundemøde: „siden vi indførte fast test før udrulning, har vi ikke haft én eneste fejl på produktion“.
Alt, der rører plugins, temaer, indstillinger eller struktur – ja. Rent indhold (tekster, indlæg, produkter) og dokumenterede sikkerhedshastefix er de to undtagelser.
Overskriv aldrig hele databasen på en levende shop – den indeholder ordrer oprettet siden klonen. Udrul filer/kode, og genskab de databasenære ændringer målrettet, eller udrul i et kort, varslet vindue.
Aftal en standard i driftsaftalen: „uden svar inden X dage udruller vi, medmindre I siger stop“. Så blokerer tavshed ikke driften – og kunden har stadig altid haft muligheden.
