Publicerad
Kunder vi arbetar med
:quality(75)){kind=logo}
Inför en kampanjtopp behöver ni bestämma vilka ändringar som får göras, hur ni provar belastning och vem som tar beslut om en release måste stoppas. En tydlig beredskapsplan är mer användbar än ett löfte om att allt ska hålla.
Utgå från kampanjens viktigaste flöden: inloggning, produkt, sök, kassa, betalning och order. Bestäm när vanliga releaser upphör och vad som räknas som en kritisk rättning. Shopify beskriver sin egen kodfrysning inför BFCM som en period där endast kritiska rättningar släpps; se det som ett exempel på arbetssätt, inte som en universell regel.
Ha en versionerad rollback-plan för varje förändring som ändå kan behöva göras. Microsoft pekar på att återställning av databas- och schemaändringar kan vara särskilt komplex; kontrollera därför återställningen innan ni är under tidspress. Läs även om lösningsarkitektur när driftkrav ska översättas till tekniska beslut.
Före fryspunkten: testa de viktigaste kundflödena under last och dokumentera kända begränsningar.
Under kodfrysningen: godkänn bara avgränsade, återställningsbara ändringar.
Under kampanjen: följ överenskomna signaler, eskaleringsvägar och kontaktlista.
Efteråt: samla avvikelser innan nästa topp.
AWS och Adobe rekommenderar båda att test, rollback och övervakning planeras före hög belastning. Vilka tester som behövs beror på er arkitektur och trafikbild; sätt inga generella kapacitetslöften i planen.
Den tekniska checklistan behöver möta kampanjteamets prisarbete. Konsumentverket anger att tidigare pris vid prissänkning ska vara det lägsta pris som använts de senaste 30 dagarna och visas nära det nedsatta priset. Låt därför någon äga kontrollen av prisdata och kampanjtexter före publicering.
För kassa och betalning kan ni komplettera med Norce Commerce i praktiken. Den här artikeln handlar däremot om beredskap, inte om att välja kassa.
Boka ett inledande samtal om ni vill strukturera beredskapen inför nästa kampanjtopp.
Konsumentverket om prissänkningar, Adobe holiday readiness, Microsoft om säkra utrullningar och AWS om automatiserade releaser. Åtkomna 2026-11-08.
När ni har tid att testa de flöden som inte längre ska ändras. Datumet måste sättas utifrån er miljö och er riskbild.
Nej. En rollback beskriver hur en specifik förändring tas tillbaka. Backup och återställning behöver planeras och testas separat.
Inte nödvändigtvis. Definiera i stället vilka kritiska ändringar som får undantag och vem som godkänner dem.
