Slik endres Macct — testet, gjennomgått, godkjent

Veien hver endring må gå

Enten det er en ny funksjon, en feilretting eller en tekstendring på én linje, gjelder de samme fire portene. Ingen av dem kan hoppes over, og rekkefølgen endres aldri.

Endringen bygges og testes i et eget testmiljø — aldri i produksjon. Testmiljøet kjører mot en anonymisert kopi av produksjonsdata, fornyet hver natt, så endringer prøves på data som oppfører seg som ekte data uten å være det.
Endringen legges fram som en pull request på GitHub. Et menneske leser gjennom og godkjenner før noe settes i drift — ingen endring når produksjon uten den gjennomgangen, og hver endring kan for alltid spores til hvem som skrev den, hvem som godkjente den og når.
Over 1 500 automatiske tester må være grønne. De vokter selve regnskapslogikken: at hvert bilag balanserer, at MVA beregnes og gjøres opp riktig, at lønn, årsoppgjør og valutaomregning gir samme riktige svar hver gang.
Først etter godkjenning settes endringen i produksjon — med samme automatiserte prosedyre hver gang, og en selvtest som verifiserer at sidene faktisk svarer etterpå. Er noe galt, blir forrige versjon stående.

Dine data er aldri testdataene

Testing rører aldri produksjonsdata. Testmiljøet får en vasket kopi: kontaktopplysninger anonymiseres og alle nøkler og tilganger fjernes, mens regnskapsstrukturen beholdes intakt — for en endring som virker på lekedata og feiler på virkelig bokføring, er akkurat den typen feil vi tester for å fange.

Endringer i selve databasen følger samme disiplin. Hver skjemaendring er en nummerert, versjonert migrasjon som tørrkjøres mot en kopi av databasen før den slipper i nærheten av produksjon. Hovedboken din konverteres aldri for hånd, og aldri i blinde.

Systemet kontrollerer seg selv mens du sover

Tester fanger feil før en endring slippes. Kontinuerlige kontroller fanger det som likevel skulle slippe forbi — og de kjører på fast tid, enten noen følger med eller ikke.

Hver natt

Avstemminger

Kunde- og leverandørsaldoer avstemmes mot hovedboken, og hvert lagret valutabeløp etterprøves mot kursen det ble bokført med. Et avvik utløser alarm samme natt — ikke ved årsoppgjøret.

Daglig og ukentlig

Sikkerhetskopier som faktisk gjenopprettes

Sikkerhetskopier tas daglig og lagres eksternt i et annet datasenter. Og fordi en utestet sikkerhetskopi bare er et håp, gjennomføres full gjenoppretting fra dem på fast plan — en kopi teller ikke før den har vært vekket til live.

Hver uke

Et helt regnskapsløp

En kanari-kjøring oppretter et ferskt selskap og tar det gjennom hele løpet — inngående balanse, fakturaer, kjøp, lønn, rapporter, årsavslutning — og kryssjekker hvert resultat mot hovedboken før alt rigges ned igjen.

Åpenhet er en del av konstruksjonen

Du skal ikke måtte ta vårt ord for noe av dette. Hver versjon av Macct bærer et synlig versjonsnummer med sin endringslogg, én linje per utgivelse, lesbar inne i appen. Reglene vi håndhever ligger åpent, paragraf for paragraf, med lovhenvisningene — og hver sats vi regner med bærer kilden sin, så du kan kontrollere oss i stedet for å stole på oss.

Reglene, paragraf for paragraf · Slik holdes satsene oppdatert · Lovkravene, ett for ett

Hva vi ikke lover

Vi kommer ikke til å fortelle deg at feil ikke kan skje. Programvare bygges av mennesker, og mennesker gjør feil — også vi. Det hele denne siden beskriver, er maskineriet som finnes nettopp derfor: feil gjøres i testmiljøet i stedet for i regnskapet ditt, fanges av en gjennomgang eller en test i stedet for av deg, og når én likevel slipper gjennom, finnes den av en nattlig kontroll, spores til den eksakte endringen som forårsaket den, og rulles tilbake. Det er løftet — ikke feilfrihet, men kort avstand mellom en feil og oppdagelsen av den.

Ingen endring går rett inn i regnskapet ditt