Driftsmæssig excellence - DevOps-mønstre
Læs mere om veludviklet operativ excellence → DevOps Practices
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Opsætning af versionskontrol | ✅ Alle metadata, der er lagret i Git-kildeformat ved brug af Salesforce DX med .forceignore konfigureret til at ekskludere irrelevante filer. Alle teammedlemmer duplikerer fra det centrale lager |
| Scratch-organisationsanvendelse | ✅ Udviklere opretter begrænsede scratch-organisationer fra kilden til funktionsarbejde, bekræfter ændringer tilbage til versionskontrol og kasserer scratch-organisationer efter funktionsfuldførelse |
| Bekræft meddelelser | ✅ Hvert bekræftelse inkluderer en tydelig og præcis meddelelse, der forklarer, hvad der er ændret, og hvorfor. Meddelelser følger teamkonventionen (f.eks. “feat:”, “fix:”, “docs:“) |
| Ændringssporing | ✅ Hver metadatamodifikation, der registreres i versionskontrol med dokumentopretteridentitet, tidsstempel og differentiering, der viser nøjagtige ændringer |
| Kodegennemgangsproces | ✅ Alle produktionsbundne ændringer forløber gennem pull-anmodninger, der kræver gennemgangsgodkendelse før fletning. deklarativ konfiguration modtager den samme kontrol som kode |
| Tilbagerulningsprocedurer | ✅ Tidligere versioner kan gendannes fra Git-historikken gennem Checkout eller tilbagerulningshandlinger. Teamet har dokumenteret tilbagerulningsprocedurer, der er testet i ikke-produktion |
| Revisionsspor | ✅ Fuldfør ændringshistorik bevaret i versionskontrol, der understøtter overensstemmelseskrav og sikkerhedsundersøgelser |
| Forgreningsstrategi | ✅ Ensartet Git-forgreningsmodel (GitFlow, GitHub-forløb eller stambaseret), der passer til teamstørrelse og frigivelsesfrekvens, dokumenteret og håndhævet |
| Migrering fra organisationsbaseret | ✅ Overgang til kildestyret udvikling fuldført tidligt i løsningens livscyklus, før vaner bliver fastgjort omkring organisationsbaseret udvikling |
| .gitignore-konfiguration | ✅ Lageret udelader genererede filer, brugerspecifikke indstillinger og legitimationsoplysninger. Inkluderer kun kildefiler, som teams har til hensigt at versionere |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Organisation som kilde til sandhed | ⚡️ Udvikling sker direkte i delte sandboxes med metadata eksporteret til versionskontrol som eftertænkt. Organisationer og versionskontrol afviger ved at oprette implementeringsfejl |
| Utilstrækkelig .gitignore | ⚡️ Lageret inkluderer genererede filer, brugerspecifikke indstillinger, store binære filer eller legitimationsoplysninger, udløser lageret og risikerer sikkerhedseksponering |
| Uigennemsigtige bekræftelsesmeddelelser | Bekræftelser som “rett fejl” eller “opdateringer” giver ingen kontekst for, hvad der er ændret, eller hvorfor. Forhindrer revisionsundersøgelser og fremtidig vedligeholdelse |
| Store sjældne bekræftelser | ⚡️ Udviklere bekræfter store ændringssæt ugentligt i stedet for små trinvise bekræftelser flere gange dagligt. Svært at gennemse, vanskeligt at isolere fejl |
| Bekræft direkte til hoved | ⚡️ Udviklere overfører ændringer direkte til hoved-/produktionsforgreningen ved at tilsidesætte gennemgang og validering. |
| Ingen forgreningsstrategi | Team mangler ensartet forgreningsmodel. Udviklere opretter vilkårlige forgreningsnavne og flettemønstre. Opretter forvirring og flettekonflikter |
| Binære filer i Git | ⚡️ Store binære filer (PDF’er, videoer, arkiver), der er bekræftet til Git, nedsætter lagringsstørrelsen og nedsætter hastigheden af duplikeringshandlinger |
| Bekræftelse af legitimationsoplysninger | API-nøgler, adgangskoder, integrationslegitimationsoplysninger eller sikkerhedstokener, der er bekræftet til versionskontrol. Opretter sikkerhedssårbarhed, selv efter fjernelse fra senere bekræftelser |
| Ignorering af flettekonflikter | ⚡️ Flettekonflikter løst ved at acceptere en side uden analyse, mister ændringer eller introducerer fejl |
| Ingen bekræftelse af forpligtelse | ⚡️ Team bekræfter aldrig, at bekræftede metadata faktisk repræsenterer tilsigtede ændringer. Metadataformatfejl eller utilsigtede ændringer springer igennem |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Developer-sandboxes | ✅ Individuelle udviklere bruger Developer-sandboxes til funktionsarbejde, enhedstest og hurtig iteration. Hver udvikler har et dedikeret miljø |
| Developer Pro-sandboxes | ✅ Teams, der udvikler administrerede pakker eller kræver højere lagringsgrænser, bruger Developer Pro-sandboxes til samarbejde |
| Delvise kopi-sandboxes | ✅ Integrationstest bruger Delvis kopi-sandboxes med repræsentative dataeksempler (10.000 registreringer pr. objekt), der er konfigureret via dataskabeloner |
| Fuld kopi-sandboxes | ✅ Ydeevnetest, produktionslignende faseinddeling og datamigreringsvalidering bruger Full Copy-sandboxes, der indeholder komplette produktionsdata og konfiguration |
| Datafølsomhedskontroller | ✅ Full Copy sandbox adgang begrænset til roller, der kræver produktionsdata; Shield Platform Encryption datamaskering anvendes til ikke-produktionsbrug, når det er relevant |
| Konfiguration af integrationsslutpunkt | ✅ Hvert sandbox-niveau opretter forbindelse til tilsvarende testslutpunkter for eksterne integrationer. Produktionsintegrationer opretter aldrig forbindelse fra sandboxes |
| Miljøspecifik konfiguration | ✅ Integrationsarkitektur bruger tilpassede metadatatyper eller tilpassede indstillinger til at eksternere slutpunkts-URL’er, legitimationsoplysninger og funktionsflag pr. miljø |
| Efter-opdateringsautomatisering | ✅ Sandbox-opdateringer udløser automatiserede Salesforce CLI, der gendanner sandbox-specifikke indstillinger, herunder integrationslegitimationsoplysninger, test af datasæd, funktionsflagstilstande og maillevering |
| Opdater planlægning | ✅ Sandbox-opdateringstidsplan dokumenteret og kommunikeret. Opdateringer planlagt i perioder med lav aktivitet for at minimere teamafbrydelse |
| Dataskabeloner | ✅ Delvis kopi-sandboxes bruger veldesignede dataskabeloner, der vælger repræsentative data på tværs af objekter og bevarer referenceintegritet |
| Navngivningskonventioner | ✅ Sandboxes følger en tydelig navngivningskonvention, der angiver formål, ejer og opdateringscyklus (f.eks. “dev-integration-q2”, “uat-release-2-4”) |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Delt udvikling-sandbox | ⚡️ Alle udviklere arbejder i en enkelt delt sandbox, der overskriver hinandens ændringer. Opretter forvirring om, hvad der er implementerbar tilstand |
| Forældede sandboxes | ⚡️ Sandboxes, der ikke er opdateret i måneder, afviger væsentligt fra produktionskonfigurationen. Test i ikke-repræsentative miljøer fører til implementeringsfejl |
| Ingen dataadministration i fuld kopi | Full Copy-sandboxes, der indeholder produktions-PII, finansielle data, HIPAA-data, der er tilgængelige for hele udviklingsteamet uden adgangskontroller eller datamaskering |
| Produktionsintegrationer fra sandbox | ⚡️ Sandboxes opretter direkte forbindelse til produktionsintegrationsslutpunkter, hvilket skaber risiko for testtransaktioner, der påvirker produktionsdata eller eksterne systemer |
| Manuel efter-opdateringskonfiguration | ⚡️ Sandbox-opdateringer kræver timer med manuel omkonfiguration af gendannelsesindstillinger. Overhead fraråder opdatering af sandboxes så ofte, som det er nødvendigt |
| Ingen sandbox-dokumentation | Team mangler dokumentation om sandbox-formål, opdateringsplaner, dataindhold eller adgangsprocedurer. Udviklere gætter, hvilket miljø de skal bruge til hvilket formål |
| Enkelt miljøtype | Team bruger kun en sandbox-type (typisk Developer eller Full Copy) til alle formål. Mangler fordele ved relevant sandbox-strategi pr. aktivitet |
| Sandbox-samling | ⚡️ Sandboxes, der er tildelt til enkeltpersoner eller projekter og aldrig frigives, når de ikke længere er nødvendige; kunstig mangel på trods af tilgængelige licenser |
| Utilstrækkelige testdata | ⚡️ Testdata i sandboxes repræsenterer ikke produktionsdatakarakteristika (volumener, relationer, kantsager). Test i urealistiske miljøer ignorerer produktionsproblemer |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Fasen Kildebekræftelse | ✅ Udviklere bekræfter ændringer af funktionsforgreninger i Git med tydelige bekræftelsesmeddelelser, der forklarer kontekst og logik |
| Fase for statisk analyse | ✅ Salesforce Code Analyzer scanner Apex for sikkerhedssårbarheder (OWASP Top 10), ydeevne-anti-mønstre (SOQL i løkker, DML i løkker), kodekvalitetsproblemer (kompleksitet, duplikering) og styringsbegrænsningsrisici. Kører i sekunder giver øjeblikkelig feedback |
| Enhedstestfase | ✅ Apex udfører validering af forretningslogik og styringsbegrænsningsoverensstemmelse i en midlertidig scratch-organisation eller en dedikeret integrations-sandbox; korrekt isolerede test fuldføres på under 5 minutter |
| Fasen Valideringsimplementering | ✅ Metadata implementeres i integrations-sandbox ved brug af Salesforce CLI med –checkonly-flag til kun validering-implementering af kørende test uden at foretage ændringer |
| Fasen Integrationstest | ✅ Automatiserede test validerer arbejdsflows med flere komponenter, eksterne integrationskontrakter, platformsbegivenhedsforløb og asynkrone behandlingskæder op mod delt integrationsmiljø med testdatastyring |
| Sikkerhedsscanningsfase | ✅ Yderligere sikkerhedsværktøjer scanner for hardcodede legitimationsoplysninger, sårbare afhængigheder, CRUD/FLS-overtrædelser og overtrædelser af compliancepolitikker. |
| UAT-implementeringsfase | ✅ Ændringer, der overfører alle automatiserede porte, implementeres i brugeraccepttestmiljøet til forretningsvalidering. Implementering kan være automatiseret eller kræve manuel godkendelse baseret på ændringsrisiko |
| Fasen Produktionsimplementering | ✅ Efter UAT-godkendelse implementeres ændringer til produktion med automatiseret et-klik-kørsel, omfattende logføring og mulighed for øjeblikkelig tilbagerulning |
| Pipeline-kørselstid | ✅ End-to-end-pipeline fuldføres på under 15 minutter for typiske ændringer, der aktiverer hurtig feedback. Længere for store implementeringer eller omfattende testsuiter |
| Opbyg artefakter | ✅ Pipeline bevarer implementeringspakker, testresultater, sikkerhedsscanningsrapporter og kørselslogfiler til overensstemmelse og fejlfinding |
| Pipeline-værktøjer | ✅ Teams bruger Salesforce DevOps Center til platformsindbyggede CI/CD’er eller integrerer med eksterne platforme (GitHub Actions, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Fejloplysninger | ✅ Pipelinefejl udløser adviseringer til bekræftelsesopretter og relevante kanaler med diagnostisk kontekst, der aktiverer hurtig rettelse |
| Forgreningsbeskyttelse | ✅ Hoved-/produktionsforgreninger, der er beskyttede, og som kræver, at de passerer CI-kontroller og godkendte gennemgange, før de flettes. Direkte bekræftelser forhindres |
| Miljøreklamering | ✅ Ændringsforløb gennem defineret reklamekampagnesti (dev → integration → UAT → production) med validering i hver fase |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Manuel implementering | ⚡️ Ændringer, der implementeres manuelt via ændringssæt eller Salesforce CLI med inkonsekvente trin, menneskelige fejl, manglende trin, manglende revisionsspor |
| Ingen statisk analyse | Pipelines ignorerer Salesforce Code Analyzer eller lignende værktøjer. Sikkerhedssårbarheder, ydeevne-anti-mønstre, kodekvalitetsproblemer når produktion |
| Utilstrækkelig test | Pipeline validerer kun mindst 75 % dækning uden at køre integrationstest eller validere nøglebrugerforløb. Regressioner glider gennem |
| Ingen sikkerhedsscanning | ⚡️ Pipelines scanner aldrig for hardcodede legitimationsoplysninger, sårbare afhængigheder eller CRUD/FLS-overtrædelser. Sikkerhedsproblemer opdages i produktions- eller sikkerhedsgennemgange |
| Kørsel af langsom pipeline | ⚡️ End-to-end-pipeline tager 45-60+ minutter, hvilket afskrækker hyppige bekræftelser og nedsætter hastigheden af feedbackkørsler. Udviklere bekræfter sig mindre hyppigt og akkumulerer større ændringer |
| Ignorerede pipelinefejl | ⚡️Teams ignorerer eller tilsidesætter pipelinefejl for at overholde deadlines. Kvalitetsgateways bliver teater snarere end faktiske kontroller |
| Ingen testmiljøparitet | ⚡️ CI/CD valideres i miljø med forskellige konfigurationer, grænser eller datakarakteristika end produktion. Overførsel af validering garanterer ikke produktionssucces |
| Manglende tilbagerulningsfunktion | ⚡️ Pipeline automatiserer implementering, men giver ingen automatiseret tilbagerulning. Gendannelse fra forkert implementering kræver manuelle nødserviceprocedurer |
| Ingen implementeringslogfiler | ⚡️ Implementeringer udført uden omfattende logføring. Fejlfinding af fejl eller revision af implementeringer bliver vanskelig |
| All-or-nothing-test | ⚡️ Pipeline kører alle test for hver ændring, uanset hvad der er ændret. 30 minutters testsuite kører selv for dokumentationsopdateringer |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Funktionsflag | ✅ Implementer ændringer med høj risiko med funktioner, der er inaktiveret bag tilpasset metadatatype eller tilpasset indstillingskonfiguration. Aktiverer test i produktion uden brugereksponering, gradvis udrulning til segmenter, A/B-test og øjeblikkelig tilbagerulning via konfigurationsændring |
| Omfang for funktionsflag | ✅ Funktionsflag, der er reserveret til ændringer med høj risiko, der påvirker vigtige forretningsprocesser, handlinger, hvor der skelnes mellem ydeevne og nye integrationsmønstre. Ikke alle funktioner har brug for markeringer |
| Canary-implementeringer | ✅ Forretningskritiske ændringer frigives til små brugersæt først (5-10 % via tilladelsessæt eller brugerattributfiltrering). Canary cohort overvåges intensivt 24-48 timer for at måle succesfrekvenser, ydeevne, fejlfrekvenser før udvidelse af udrulning |
| Implementeringsvinduer | ✅ Implementeringer, der er planlagt i perioder med lav anvendelse, informeret af Event Monitoring API-anvendelseslogfiler, der viser faktiske trafikmønstre. Undgår spidsanvendelse, månedsslut lukning, kvartalsslut lukning, større forretningsbegivenheder |
| Implementeringskommunikation | ✅ Interesserede modtager advisering på forhånd om implementeringsvinduer, herunder forventet varighed, påvirket funktionalitet og tilbagerulningsbeslutningslinje |
| Tilbagerulningsprocedurer | ✅ Dokumenterede og testede tilbagerulningsprocedurer for hver implementeringstype. Teamet kan udføre tilbagerulning på under 30 minutter, når der er behov for det |
| Tilbagerulningstest | ✅ Tilbagerulningsprocedurer valideret i ikke-produktionsmiljø før væsentlige implementeringer, der sikrer, at der findes gendannelsesfunktionalitet |
| Validering af implementering | ✅ Efter implementering validerer røgtest kritiske brugerforløb, integrationsslutpunkter og nøglefunktionalitet umiddelbart efter frigivelse |
| Rediger koordination | ✅ Koordineret implementeringsstrategi, når ændringer strækker sig over flere systemer eller kræver synkroniserede versioner på tværs af Salesforce og eksterne platforme |
| Overvågning under implementering | ✅ Forbedret overvågning aktiv under implementeringsvinduet og efter implementeringsobservationsperiode (24-48 timer) til at se efter spidser for fejlfrekvens, ydeevneforringelse eller brugerforløbsfejl |
| Blå-grønt mønster for integrationer | ✅ Eksterne tjenester, der vises i Salesforce, bruger blå-grønne implementeringer, der vedligeholder to produktionslignende miljøer, implementerer til inaktive først, skifter trafik efter validering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Big Bang-implementeringer | ⚡️ Store versioner, der indeholder mange funktioner, omstruktureringer og ændringer, der implementeres samtidigt uden nogen gradvis udrulning. Fejl påvirker alle brugere med det samme |
| Peak hour-implementeringer | ⚡️ Versioner, der er planlagt i spidsbelastningstider (middag, slutning af måned, slutning af kvartal), når anvendelsen er højst, og brugerpåvirkningen af problemer maksimeres |
| Ingen tilbagerulningsplan | ⚡️ Implementeringer fortsætter uden dokumenterede og testede tilbagerulningsprocedurer. Når der opstår problemer, forsøger teamet at finde ud af, hvordan det skal gendannes |
| Funktionsomskifter som Eftertænkning | ⚡️ Funktionsflag tilføjes genaktivt, når der opstår problemer, snarere end proaktivt designet til ændringer med høj risiko. Begrænser tilbagerulningsindstillinger til fuld implementeringsomvendelse |
| Ingen implementeringsvalidering | ⚡️ Ændringer, der er implementeret i produktion uden efter implementering-røgtest. Teamet antager, at implementeringen lykkedes og fortsætter. Problemer, der opdages timer senere af brugere |
| Ikke-testede tilbagerulningsprocedurer | ⚡️ Tilbagerulningsprocedurer dokumenteret, men aldrig testet i ikke-produktion. Under en faktisk hændelse mislykkes eller viser proceduren sig utilstrækkelig |
| Samtidig ændring af flere systemer | ⚡️ Koordinerede ændringer på tværs af Salesforce og eksterne systemer, der er implementeret uden synkronisering eller kompatibilitetstest. Opretter integrationsfejl |
| Ingen overvågningsforbedring | ⚡️ Implementeringer fortsætter uden forbedret overvågning under implementeringsvinduet. Problemer registreres via brugerklager snarere end proaktive advarsler |
| Weekend-implementeringer | ⚡️ Større versioner implementeret fredag aften eller i weekender, når on-call-dækning reduceres, og tilgængeligheden af leverandørsupport er begrænset |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Enhedstestdækning | ✅ Meningsfuld testdækning, der validerer forretningsregler, kantsager, fejlstier og styringsbegrænsningstilgang. Overskrider 75 % af minimumkravet |
| Enhedstestkvalitet | ✅ Test validerer forretningslogik, ikke platformsfunktionalitet. Velskrevne enhedstest er hurtige (milisekunder), isolerede (ingen delt tilstand) og fokuserede (hver test validerer en adfærd) |
| Test datastrategi | ✅ Test bruger @TestSetup-metoder til almindelige testdata. Undgå SOQL-forespørgsler i test, hvor det er muligt. Brug Test.loadData() til at indlæse statiske ressourcer |
| Skjul eksterne afhængigheder | ✅ Enhedstest imiterer eksterne udkald ved brug af teststubs og afhængighedsinjektion, der aktiverer hurtig kørsel uden faktiske HTTP-anmodninger |
| Integrationstest | ✅ Valider interaktioner mellem udløsere, forløb, platformsbegivenheder, batchjob og eksterne udkald, der kører i sandboxes med repræsentative testdata |
| Integrationstest - pålidelighed | ✅ Integrationstest kan gentages og er deterministiske. Sporadiske fejl håndteres gennem synkroniseringsmekanismer som platformsbegivenheds-genafspilnings-id’er og batchjobpolling |
| Slut-til-slut-test | ✅ Automatiseret browsertest (Selenium, Playwright, Provar) validerer komplette brugerrejser for forretningskritiske forløb, der udøver systemet gennem brugergrænsefladen nøjagtigt, når brugere interagerer |
| E2E-testfokus | ✅ E2E-test fokuserer på højeste værdi af brugerstier på grund af langsommere kørsel (minutter pr. test) og højere vedligeholdelsesbelastning fra brugergrænsefladens ændringer |
| Indlæsningstest | ✅ Ydeevne valideret under realistiske samtidige brugerindlæsninger og datamængder ved brug af Salesforce-indlæsningstesttjenester eller tredjepartsværktøjer; afslører styringsbegrænsningsproblemer, låseafstemning, ydeevnedegradering |
| Indlæs testfrekvens | ✅ Indlæsningstest køres før større versioner og regelmæssigt (kvartalsvis) for at validere ydeevne ved 3x-5x aktuelle produktionsmængder |
| Testpyramide | ✅ Afbalanceret testfordeling: mange enhedstest (hundreder, minutter), færre integrationstest (doser, minutter), få E2E-test (under 20 minutter); hurtig feedback ved basisen, omfattende validering øverst |
| Testisolering | ✅ Test afhænger ikke af hinanden. De kan køre i enhver rækkefølge. Hver test forlader systemet i ren tilstand eller bruger @TestSetup til ensartet startpunkt |
| Negative testsager | ✅ Test validerer fejlhåndtering, håndhævelse af valideringsregler, tilladelseshåndhævelse og fornuftig nedgradering under ugunstige betingelser |
| Styringsbegrænsningstest | ✅ Test validerer specifikt adfærd, der nærmer sig styringsbegrænsninger, herunder SOQL-forespørgselsgrænser, DML-grænser, CPU-tid, heap-størrelse |
| Kontinuerlig testkørsel | ✅ Test kører automatisk på hvert bekræftelse via CI/CD-pipeline. Mislykkede test forhindrer implementering i højere miljøer |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Test af dækning | ⚡️ Test skrevet udelukkende for at opnå 75 % minimumdækning uden at validere forretningsregler eller kantsager. Test, der ikke påstår noget eller tester trivielle kodestier |
| Test af platformsfunktionalitet | ⚡️ Test validerer, at Salesforce gemmer registreringer eller SOQL-forespørgsler arbejde i stedet for validering af forretningslogik. Spildt indsats på platformsgarantier |
| Ingen mock-strategi | ⚡️ Enhedstest foretager faktiske udkald til eksterne systemer. Test er langsomme, skrøbelige over for ekstern systemtilgængelighed og forbruger API-grænser |
| Sporadiske testfejl | ⚡️ Test passerer eller mislykkes uventet baseret på kørselstidspunkt, datatilstand eller testkørselsrækkefølge. Teams lærer at ignorere fejl og køre igen, indtil test passerer |
| Ingen integrationstest | ⚡️ Kun enhedstest findes. Team validerer aldrig, at udløsere, forløb, platformsbegivenheder og batchjob fungerer sammen korrekt |
| Kun manuel E2E-test | ⚡️ Kritiske brugerforløb valideret manuelt før hver version, ingen automatiserede E2E-tests, regressioner fundet i produktion, når manuel test går glip af scenarier |
| Ingen indlæsningstest | ⚡️ Ydeevne er aldrig valideret under realistiske samtidige indlæsninger. Styringsbegrænsningsproblemer, låseafstemning eller ydeevnedegradering opdages i produktion |
| Test af afhængigheder | ⚡️ Test afhænger af specifikke registreringer, der findes i organisationen eller antager en bestemt brugerkonfiguration. Afbrydes, når sandboxen opdateres eller konfigurationen ændres |
| Ingen negative testsager | ⚡️ Test validerer kun lykkelige stisscenarier. Test aldrig fejlhåndtering, valideringshåndhævelse eller tilladelseskontroller. Fejltilstande ikke fundet |
| Ignorerede test | ⚡️ Mislykkede test kommenteret ud af @isTest og ignoreret i stedet for rettet. Testsuite nedsættes over tid, efterhånden som flere test ignoreres |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Gennemse dækning | ✅ Alle produktionsbundne ændringer forløber gennem kodegennemgang via pull-anmodninger, der kræver godkendelse før fletning; inkluderer Apex, Aura, LWC, forløb, valideringsregler, tilladelsessæt, delingsregler |
| Gennemse kriteriecheckliste | ✅ Eksplicit tjekliste, der dækker sikkerhed (CRUD/FLS-håndhævelse, inputvalidering), ydeevne (bulkifikation, SOQL-optimering), styringsbegrænsningsoverensstemmelse (behandlingsmønstre, rekursionsforebyggelse), vedligeholdelighed (navngivning, dokumentation, kompleksitet), testdækning (meningsfulde test, kantsager), arkitektonisk ensartethed (designmønstre, adskillelse af bekymringer) |
| Gennemse størrelsesgrænser | ✅ Hent anmodninger, der bevares under 400 linjer med meningsfulde ændringer, der aktiverer grundig gennemgang. Store funktioner opdelt i mindre trinvise ændringer, der kan gennemses individuelt og kan implementeres uafhængigt |
| Gennemse tid | ✅ Gennemgange, der er fuldført inden for en arbejdsdag, bevarer udviklingstendensen og giver hurtig feedback. Forsinkede gennemgange skaber overhead-kontekstskift |
| Automatiserede før-gennemgangskontroller | ✅ Statisk analyse, enhedstest og sikkerhedsscanning kører automatisk, før der anmodes om gennemgang af person, automatiserede kontroller fanger mekaniske problemer, så korrekturlæsere fokuserer på design og forretningslogik |
| Distribueret gennemgang - ansvar | ✅ Ansvaret for kodegennemgang er fordelt på tværs af teamet for at forhindre flaskehalse og dele Knowledge; juniorudviklere gennemgår seniorkode og forklarer deres egen kode under gennemgang |
| Gennemse kvalitet af kommentarer | ✅ Gennemsynsmænd giver specifik feedback, der kan handles på, med begrundelse. Skelne mellem krævede ændringer (blokering af problemer) og forslag (venlige forbedringer) |
| Gennemse dokumentation | ✅ Beskrivelser af Pull-anmodninger forklarer, hvad der er ændret, hvorfor det er ændret, hvad der er udført test og eventuelle særlige implementeringsovervejelser eller tilbagerulningsprocedurer |
| Deklarativ konfigurationsgennemgang | ✅ Forløb, valideringsregler og tilladelsesændringer modtager samme gennemgangstrengthed som kode. Konfigurationen er arkitektonisk og fortjener grundig undersøgelse |
| Opfølgning på kommentarer | ✅ Alle gennemgangskommentarer, der er behandlet før fletning, besvarede spørgsmål, implementerede ændringer eller angivet grundlag for, hvorfor forslag ikke blev taget i brug |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Ingen kode-gennemgang | ⚡️ Ændringer, der er bekræftet direkte til produktionsforgreningen uden nogen peer-gennemgang. Eliminerer primær fejlregistreringsmekanisme |
| Gummistempel | ⚡️ Gennemsynsgivere godkender pull-anmodninger inden for sekunder uden faktisk at undersøge ændringer. Gennemsyn bliver afkrydsningsfeltoverensstemmelse snarere end kvalitetsport |
| Enkelt korrekturlæser - bottleneck | ⚡️ Kun en senior udvikler autoriseret til at gennemgå kode; skaber flaskehals og enkelt fejlpunkt; Knowledge koncentreret snarere end distribueret |
| Massive pull-anmodninger | ⚡️ Træk anmodninger, der indeholder tusindvis af linjer med ændringer, der strækker sig over flere funktioner. Det er umuligt at gennemgå grundigt, hvilket fører til overfladisk undersøgelse |
| Forsinkede gennemgange | ⚡️ Pull-anmodninger forbliver uanmeldte i dage eller uger. Udviklere mister kontekst og flytter til andet arbejde. Gennemgangskommentarer ankommer, når udvikleren har skiftet mental kontekst |
| Ingen gennemgangskriterier | ⚡️ Team mangler eksplicitte kriterier for, hvad korrekturlæsere skal undersøge. Gennemgangskvaliteten varierer meget efter korrekturlæsere. Nogle korrekturlæsere fokuserer på typografi, andre på logik, ingen omfattende |
| Gennemse uden test | ⚡️ Gennemsynsgivere godkender ændringer baseret på kodeinspektion alene uden at trække forgrening og teste lokalt eller validere automatiserede test passerer |
| Ignorerede automatiserede kontroller | ⚡️ Gennemsynsgivere godkender pull-anmodninger på trods af mislykkede statiske analyser, sikkerhedsscanninger eller enhedstest. |
| Kultur for fjendtlig gennemgang | ⚡️ Gennemgange bliver til personlig kritik eller konkurrencedygtig træning i stedet for samarbejdskvalitetsforbedring. Fraråder læring og psykisk sikkerhed |
| Ingen deklarativ gennemgang | ⚡️ Forløb, valideringsregler, tilladelsessæt og delingsregler implementeres uden gennemgang, mens Apex modtager gennemgang. Opretter kvalitetsmangler i deklarativ konfiguration |