Detta white paper beskriver hur en ideell patientorganisation kan förbättra stabilitet och tillförlitlighet i sina digitala system genom att införa en mer strukturerad DevOps-baserad release-process. Organisationen är beroende av sin wepplats och sina digitala kommunikationskanaler för att nå sin målgrupp som består av patienter, närstående och vårdpersonal vilket gör fungerande kommunikation särskilt viktigt.
Tidigare har ändringar i systemmiljön lett till att kontaktmeddelanden via formulär på webbplatsen inte alltid nått fram. Detta har skapat oro bland medlemmar och ökat den administrativa belastningen på styrelsen. Problemen kan till stor del kopplas till personberoende arbetssätt, avsaknad av testmiljö samt brist på automatiserad kvalitetssäkring innan förändring publicerats.
Den föreslagna lösningen är att införa en tydlig release-pipeline som fungerar som en kontrollerande länk mellan utveckling och produktion. Genom att använda automatiserade tester, tydliga kvalitetssäkringssteg och manuella godkännanden kan organisationen minska risken för fel i produktionen. Det kan samtidigt skapa ett mer förutsägbart arbetssätt som minskar personberonde och passar en ideell organisation med begränsade resurser.
Organisationen är en ideell patientförening med cirka 5000 medlemmar bestående av patienter, närstående och vårdpersonal. Föreningens uppdrag är att erbjuda stöd, information, kunskapsspridning samt bidra till påverkansarbete.
Föreningens webbplats är en av de primära kommunikationskanalerna och används för information, kontakt och medlemsregistrering. Webbplatsen innehåller bland annat ett öppet kontaktformulär kopplat till föreningens informations e-postadress och även ett separat formulär för medlemskap som hanteras av Brevo CRM med automatiserade flöden.
Tillgänglighet och korrekt funktion i dessa system är centralt då webbplatsen ofta är första kontaktvägen för personer i behov av stöd.
Föreningen lanserade sin WordPress-baserade webbplats år 2018. Drift hanterades initialt av en styrelsemedlem som ensam ansvarade för tekniska uppdateringar och administration. Hösten 2025 avgick denna person från styrelsen utan formell överlämning av tekniskt ansvar.
Utan tydliga rutiner för uppdateringar och kvalitetssäkrin aktiverades automatiska uppdateringar av wepplatsens komponenter. Detta ledde till konflikter mellan olika funktioner på webbplatsen vilket påverkade kommunikationen via wepplatsens formulär.
Konsekvensen blev att ett flertal kontaktmeddelanden inte nådde organisationen. Även om medlemsdata inte påverkades direkt så visade incidenten tydligt på riskerna emd att genomföra förändringar utan tester, kontroller eller möjlighet till återställning.
Händelsen skapade orsäkerhet hos patienter och närstående när svar på vitkiga frågor uteblev. Samtidigt behövde styrelsen lägga mycket tid på felsökning utan tillräckliga tekniska förutsättningar. Situationen tydliggjorde att organisationen i hög grad var beroende av enskilda personer snarare än tydliga och etablerade processer.
För att minska risken för framtida driftstörningar föreslås att organisationen inför en mer strukturerad release-process baserad på DevOps principer. Fokus ligger på att skapa tydliga och återkommande arbetssätt istället för att vara beroende av enskilda personers kunskap och erfarenheter.
Organisationens tekniska miljö består idag av WordPress med Elementor Pro samt Brevo SMTP och CRM. De största utmaningarna är ett tydligt personberoende, avsaknad av en separat testmiljö och brist på strukturerad kvalitetssäkring innan förändringar publiceras.
Förslag på lösning är att införa en standardiserad release-kedja där automatiserade tester fungerar som ett öfrsta kontrollsteg. Dessa kompletteras med manuella godkännanden vid förändringar som påverkar kommunikationen eller hanteringen av personuppgifter. Detta kan följande öka organisationens stabilitet i sina system utan att förlora den flexibilitet som krävs i ideellt arbete.
Release-kedjan beskriver hur en förändring går från utveckling till produktion på ett kontrollerat sätt:
1. Förändring görs i kod eller konfiguration
2. Förändringen versionhanteras
3. Automatiserade tester körs
4. Integrationer verifieras
5. Förändring granskas manuellt
6. Publicering sker till produktionsmiljö
7. Funktion följs upp efter release
Organisationen använder Continuous Delivery istället för fullständig Continuous Deployment. Detta innebär att alla förändringar testas automatiskt och görs redo för produktion men själva publiceringen sker manuellt.
Release-pipelinen fungerar därmed som en automatiserad kontroll mellan utveckling och produktion. Automatiserade teester används för att tidigt upptäcka tekniska fel medan ett manuellt godkännande säkerhetställer att förändringar som påverkar verksamheten och användarna publiceras på ett kontrollerat sätt.
Testningen är riskbaserad och anpassad efter organisationens storlek och förutsättningar. Målet är att fånga fel så tidigt som möjligt i processen för att minska risken för att buggar når och orsakar problem för användare och medlemmar.
Enhetstester har högst prioritet och utgör den största delen av testningen. Dessa tester körs vid varje förändring och används för att kontrollera grundläggande funktionalitet, exempelvis formulärvalidering, korrekt konfiguration och hantering av indata. Syftet är att snabbt upptäcka enkla fel innan de sprids vidare till systemet.
Används för att säkerhetställa att olika system fungerar tillsammans efter förändringar. Exempelvis att data som skickas via webbplatsens formulär korrekt vidarebefodras till externa tjänstser. Dessa tester blir särskilt viktiga eftersom problem i integrationer tidigare orsakat driftstörningar.
Dessa tester används mer sparsamt och fokuserar på verksamhetskritiska scenarier såsom att ett kontaktmeddelande kan skickas från wepplatsen och nå organisationen. Dessa tester fungerar som en ssista konroll innnan förändringar som påverkar formulär, integrationer eller plugin-uppdateringar publiceras för slutanvändare.
Release-pipelinen fungerar som en automatiserad kontroll mellan utveckling och produktion och innehåller flera steg för ssäkring.
Tester och grundläggande verifieringar körs automatiskt tidigt i pipelinen. Om ett test misslyckas stoppas processen direkt, vilket gör att fel inte ska gå vidare mot produktion. Detta gör att tekniska problem tidigare kan upptäckas och åtgärdas innan de påverkar användare.
Innan publicering till produktionsmiljön krävs ett manuellt godkännande. Detta är särskilt viktigt vid förändringar som påverkar kommunikation, formulär eller hantering av personuppgifter där även organisatoriska och juridiska aspekter nehöver beaktas.
Genom att kombinera automatiska tester med manuella kontroller kan en balans mellan teknisk kvalitetssäkring och mänsklig kontroll skapas där risken är som störst.
Ansvarsfördelningen är utformad för att minska personberoende och för att skapa tydlighet i processen.
Utvecklare eller personer med tekniskt ansvar:
- Tekniska förändringar i kod, konfigueration eller integrationer utförs av utvecklare eller personer med tekniskt ansvar i styrelsen. Dessa förändringar hanteras via en automatiserad CI/CD-pipeline som används för Continuous Delivery. Pipelinen ansvarar för attköra tester och genomföra grundläggande kontroller samt stoppa förändringar som inte uppfyller kvalitetskraven.
Webb- eller kommunikationsansvarig:
- Själva publiseringen till produktionsmiljön sker inte automatiskt utan kräver istället ett manuellt godkännande från webb- eller kommunikationsansvarig innan förändringar görs aktiva. Godkännande sker via kontrollerad åtkomst till relevanta system eller via manuellt steg i release-pipelinen, exempelvis med särskilda behörigheter såsom administratörskonton för att minska risk för otydliga elelr delade inlogg. Detta gäller särskilt vid plugin-uppdateirngar, ändringar i formulär eller justeringar av integration som påverkar extern kommunikation eller hantering av personuppgifter.
Övergripande ansvar:
- Styrelsen har det övergripande ansvaret för riktlinjer, prioriteringar och riskbedömning kopplat till organisationens digitala närvaro.
Valet av deployment-metod är centralt eftersom organisationen tidigare haft problem med personberoende, bristande kvalitetssäkring och risken att felaktiga uppdateringar når användare.
Organisationena bör därför använda Continuous Delivery istället för Cintinuous Deployment. Automatisk publicering till produktion bedöms som för riskfylld då organisationens webbplats är en viktig kanal för kommunikation, kontakt och hantering av personuppgifter. Tidigare problem med integrationer och uppdateringar har visat att fel i produktionen kan få direkta konsekvenser för användare och medlemmar.
Continuous Delivery innebär att alla förändringar automatiskt byggs, testas och förbereds för produktion men att sjävla publiceringen kräver ett manuellt godkännande innan ändringar blir synliga. Detta gör det möjligt att upptäcka tekniska fel tidigt samtidigt som organisationen behåller kontroll över när förändringar publiceras.
För en ideell organisation med begränsade resurser och där styrelsearbetet sker ideellt och den tekniska biten varierar kan detta bidra till ett mer förutsägbart arbetssätt. Automatiserad kvalitetsäkring minskar risken för fel medan manuella godkännande bidrar till trygghet, minskad sterss och tydligare ansvar vid publicering.
on:
push:
branches:
- mainRelease-pipelinen startar automatiskt när någon gör en förändring exempelvis kod, konfiguration eller dokumentation. När pipelinen triggars körs tester och annan kvalitetssäkring innan förändringen godkännas för publicering.