Operativ förträfflighet - DevOps-mönster
Få reda på mer om välarkitekturerad operativ excellens → DevOps-rutiner
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Konfiguration av versionshantering | ✅ Alla metadata som lagras i Git källformat med Salesforce DX projektstruktur med .forceignore konfigurerad att utesluta irrelevanta filer; alla teammedlemmar klona från centralt arkiv |
| Användning av skissorganisationer | ✅ Utvecklare skapar flyktiga skissorganisationer från källa för funktionsarbete, överlämna ändringar tillbaka till versionskontroll och ignorera skissorganisationer efter att funktionen slutförts |
| Bifoga meddelanden | ✅ Varje åtagande innehåller tydliga, koncisa meddelanden som förklarar vad som ändrats och varför; meddelanden följer teamkonvention (t.ex. “feat:”, “fix:”, “docs:“) |
| Ändringsspårning | ✅ Varje metadataändring som samlats in i versionshantering med författares identitet, tidsstämpel och jämförelse som visar exakta ändringar |
| Kodgranskningsprocess | ✅ Alla produktionsbundna ändringar flödar genom hämtningsbegäranden som kräver granskningsgodkännande innan koppling; deklarativ konfiguration får samma granskning som kod |
| Återställningsprocesser | ✅ Tidigare versioner som kan återställas från Git-historik genom Checkout eller Återställning; Team har dokumenterade återställningsprocesser testade i icke-produktion |
| Granskningslogg | ✅ Fullständig ändringshistorik bevarad i versionskontroll som stöder efterlevnadskrav och säkerhetsutredningar |
| Förgreningsstrategi | ✅ Konsekvent Git-förgreningsmodell (GitFlow, GitHub-flöde eller trunkbaserad) lämplig för teamstorlek och releasefrekvens; dokumenterad och tillämpad |
| Migrering från organisationsbaserad | ✅ Övergång till källdriven utveckling slutförd tidigt i lösningslivscykeln innan vanor stelnar kring organisationsbaserad utveckling |
| Konfiguration av .gitignore | ✅ Arkivet utesluter skapade filer, användarspecifika inställningar och inloggningsuppgifter; inkluderar endast källfiler som team avser att versionera |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Organisation som sanningskälla | ⚠️ Utveckling sker direkt i delade sandboxar med metadata exporterade till versionskontroll som eftertanke; organisationer och versionskontroll skiljer sig åt vilket skapar distributionsfel |
| Otillräcklig .gitignore | ⚠️ Arkivet inkluderar skapade filer, användarspecifika inställningar, stora binära filer eller inloggningsuppgifter; arkiv med uppblåsthet och säkerhetsexponering |
| Vaga förpliktelsemeddelanden | ⚠️ Åtaganden som “fixa bugg” eller “uppdateringar” ger inget sammanhang för vad som ändrats eller varför; hindrar granskningsundersökningar och framtida underhåll |
| Stora sällan förekommande åtaganden | ⚠️ Utvecklare utför stora ändringar varje vecka istället för små inkrementella åtaganden flera gånger dagligen; svårt att granska, svårt att isolera fel |
| Förpliktelse direkt till huvud | ⚠️ Utvecklare pushar ändringar direkt till huvud-/produktionsgrenen och kringgår granskning och validering; eliminerar kvalitetsgrindar |
| Ingen förgreningsstrategi | ⚠️ Teamet saknar en konsekvent förgreningsmodell; utvecklare skapar godtyckliga grennamn och sammanslagningsmönster; skapar förvirring och sammanslagningskonflikter |
| Binära filer i Git | ⚠️ Stora binära filer (PDF:er, videor, arkiv) engagerade i Git uppblåst arkiv storlek och sakta ner klona operationer |
| Inloggningsuppgifter | ⚠️ API-nycklar, lösenord, integreringsuppgifter eller säkerhetstokens som används för versionskontroll; skapar säkerhetsrisker även efter borttagning från senare överlämningar |
| Ignorera sammanslagningskonflikter | ⚠️ Sammanslagningskonflikter lösta genom att acceptera en sida utan analys; förlorar ändringar eller introducerar buggar |
| Ingen verifiering av åtagande | ⚠️ Teamet verifierar aldrig att överlämnade metadata faktiskt representerar avsedda ändringar; metadataformatfel eller oavsiktliga ändringar slinker igenom |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Developer Sandboxar | ✅ Individuella utvecklare använder Developer Sandboxar för funktionsarbete, enhetstest och snabb upprepning; varje utvecklare har dedikerad miljö |
| Developer Pro Sandboxar | ✅ Team som utvecklar hanterade paket eller kräver högre lagringsgränser använder Developer Pro-sandboxar för samarbete |
| Delvis kopiera sandboxar | ✅ Integreringstest använder Partial Copy sandboxar med representativa dataexempel (10 000 poster per objekt) konfigurerade via datamallar |
| Full Copy Sandboxar | ✅ Prestandatest, produktionsliknande fasning och validering av datamigrering använder Full Copy-sandboxar som innehåller fullständiga produktionsdata och konfiguration |
| Datakänslighetskontroller | ✅ Full Copy sandboxåtkomst begränsad till roller som kräver produktionsdata; Shield Platform Encryption datamaskering tillämpas för icke-produktionsanvändning när det är lämpligt |
| Konfiguration av integreringsslutpunkt | ✅ Varje sandboxnivå ansluter till motsvarande testslutpunkter för externa integreringar; produktionsintegreringar ansluter aldrig från sandboxar |
| Miljöspecifik konfiguration | ✅ Integreringsarkitektur använder egna metadatatyper eller egna inställningar för att externalisera slutpunkts-URL:er, inloggningsuppgifter och funktionsflaggor per miljö |
| Automatisering efter uppdatering | ✅ Sandboxuppdateringar utlöser automatiserade Salesforce CLI skript som återställer sandboxspecifika inställningar inklusive integreringsuppgifter, testdatasådd, funktionsflaggstater och e-postleverans |
| Uppdatera schemaläggning | ✅ Sandboxuppdateringsschema dokumenterat och kommunicerat; uppdateringar planerade under perioder med låg aktivitet för att minimera teamavbrott |
| Datamallar | ✅ Partial Copy sandboxar använder väldesignade datamallar som väljer representativa data mellan objekt som upprätthåller referensintegritet |
| Namnkonventioner | ✅ Sandboxar följer tydlig namnkonvention som indikerar syfte, ägare och uppdateringscykel (t.ex. “dev-integration-q2”, “uat-release-2-4”) |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Delad utvecklingssandbox | ⚠️ Alla utvecklare arbetar i en enskild delad sandbox och skriver över varandras ändringar; skapar förvirring om vad som är distributionsbart läge |
| Gamla sandboxar | ⚠️ Sandboxar har inte uppdaterats på flera månader och avviker avsevärt från produktionskonfigurationen; tester i ej representativa miljöer leder till distributionsfel |
| Ingen datastyrning i fullständig kopia | ⚠️ Full Copy sandboxar som innehåller produktions-PIL, ekonomiska data, HIPAA-data tillgängliga för hela utvecklingsteamet utan åtkomstkontroller eller datamaskering |
| Produktionsintegreringar från sandbox | ⚠️ Sandboxar ansluter direkt till slutpunkter för produktionsintegrering vilket skapar risk för testtransaktioner som påverkar produktionsdata eller externa system |
| Manuell konfiguration efter uppdatering | ⚠️ Sandboxuppdateringar kräver timmar av manuell omkonfigurering för att återställa inställningar; overhead avskräcker från att uppdatera sandboxar så ofta som det behövs |
| Ingen sandboxdokumentation | ⚠️ Teamet saknar dokumentation om sandboxsyften, uppdateringsscheman, datainnehåll eller åtkomstprocedurer; utvecklare gissar vilken miljö de ska använda i vilket syfte |
| Enskild miljötyp | ⚠️ Team använder endast en sandboxtyp (vanligtvis Developer eller Full Copy) för alla syften; missar fördelarna med lämplig sandboxstrategi per aktivitet |
| Sandboxhamstring | ⚠️ Sandboxar allokerade till individer eller projekt och aldrig släppta när de inte längre behövs; artificiell knapphet trots tillgängliga licenser |
| Otillräckliga testdata | ⚠️ Testdata i sandboxar representerar inte produktionsdataegenskaper (volymer, relationer, kantfall); tester i orealistiska miljöer missar produktionsproblem |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Fas för källförpliktelse | ✅ Utvecklare gör ändringar av funktionsgrenar i Git med tydliga meddelanden som förklarar sammanhang och logik |
| Fas för statisk analys | ✅ Salesforce Code Analyzer söker igenom Apex efter säkerhetsbrister (OWASP Top 10), prestandaantimönster (SOQL i loopar, DML i loopar), problem med kodkvalitet (komplexitet, dubblett) och styrande gränsrisker; körs på några sekunder och ger omedelbar feedback |
| Enhetstestfas | ✅ Apex tester utför validering av verksamhetslogik och styrande begränsar efterlevnad i flyktig skissorganisation eller dedikerad integrationssandbox; korrekt isolerade tester utförda på mindre än 5 minuter |
| Valideringsdistribueringsfas | ✅ Metadata distribueras till integreringssandbox med Salesforce CLI med flaggan –checkonly för endast valideringsdistribuering som kör tester utan att utföra ändringar |
| Integreringstestfas | ✅ Automatiserade tester validerar flerkomponentsflöden, externa integreringskontrakt, plattformshändelseflöden och asynkrona bearbetningskedjor mot delad integreringsmiljö med testdatahantering |
| Fas för säkerhetsskanning | ✅ Ytterligare säkerhetsverktyg söker efter hårdkodade inloggningsuppgifter, sårbara beroenden, CRUD / FLS-brott och efterlevnadspolicybrott; viktiga upptäckter bryter byggen |
| UAT-distribueringsfas | ✅ Ändringar som passerar alla automatiserade grindar distribueras till testmiljö för användaracceptans för verksamhetsvalidering; distribution kan automatiseras eller kräva manuellt godkännande baserat på ändringsrisk |
| Distributionsfas för produktion | ✅ Efter UAT-godkännande distribueras ändringar till produktion med automatiserat enklicksutförande, omfattande loggning och omedelbar återställningskapacitet |
| Utförandetid för pipeline | ✅ End-to-end pipeline slutförs på under 15 minuter för typiska ändringar som möjliggör snabb feedback; längre för stora distribueringar eller omfattande testsviter |
| Bygg artefakter | ✅ Pipeline bevarar distributionspaket, testresultat, säkerhetsskanningsrapporter och utförandeloggar för efterlevnad och felsökning |
| Pipelineverktyg | ✅ Team använder Salesforce DevOps Center för plattformsinbyggd CI/CD, eller integrerar med externa plattformar (GitHub-åtgärder, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Notiser om fel | ✅ Pipelinefel utlöser notiser för att binda författare och relevanta kanaler med diagnostiskt sammanhang som möjliggör snabb avhjälpande |
| Grenskydd | ✅ Huvud / produktionsgrenar skyddas som kräver att passera CI-kontroller och godkända granskningar innan koppling; direkta åtaganden förhindras |
| Miljöfrämjande | ✅ Ändringar flöde genom definierade erbjudande väg (dev → integration → UAT → produktion) med validering i varje steg |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Manuella distribueringar | ⚠️ Ändringar distribuerade manuellt via ändringsanvisningar eller Salesforce CLI kommandon med inkonsekventa steg; mänskliga fel, missade steg, avsaknad av granskningslogg |
| Ingen statisk analys | ⚠️ Pipelines hoppar över Salesforce Code Analyzer eller liknande verktyg; säkerhetsbrister, prestandaantimönster, kodkvalitetsproblem når produktion |
| Otillräckliga tester | ⚠️ Pipeline validerar endast minst 75 % täckning utan att köra integreringstest eller validera viktiga användarflöden; regressioner slinker igenom |
| Ingen säkerhetsskanning | ⚠️ Pipelines söker aldrig efter hårdkodade inloggningsuppgifter, sårbara beroenden eller CRUD/FLS-brott; säkerhetsproblem upptäckta i produktion eller säkerhetsgranskningar |
| Långsamt pipelineutförande | ⚠️ Slut-till-slut-pipeline tar 45-60+ minuter att avskräcka från frekventa åtaganden och sakta ner feedbackloopar; utvecklare åtar sig mer sällan att samla på sig större ändringar |
| Ignorerade pipelinefel | ⚠️ Team ignorerar eller åsidosätter pipelinefel när de inte uppfyller deadlines; kvalitetsgrindar blir teater snarare än faktiska kontroller |
| Ingen testmiljöparitet | ⚠️ CI/CD valideras i miljöer med andra konfigurationer, gränser eller dataegenskaper än produktion; validering garanterar inte att produktionen lyckas |
| Saknad rollbackkapacitet | ⚠️ Pipeline automatiserar distribuering men ger ingen automatiserad återställning; återställning från felaktig distribuering kräver manuella nödåtgärder |
| Inga distributionsloggar | ⚠️ Utplaceringar som utförs utan omfattande loggning; felsökningsfel eller granskning av utplaceringar blir svårt |
| Allt-eller-inget-test | ⚠️ Pipeline kör alla tester för varje ändring oavsett vad som ändrats; 30 minuters testsvit körs även för dokumentationsuppdateringar |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Funktionsflagg | ✅ Högriskändringar distribueras med funktioner inaktiverade bakom egna metadatatyper eller egen inställningskonfiguration; möjliggör tester i produktion utan användarexponering, gradvis lansering till segment, A / B-test och direkt återgång via konfigurationsändring |
| Funktionsflaggomfång | ✅ Funktionsflagg reserverade för ändringar med hög risk som påverkar viktiga verksamhetsprocesser, prestandakänsliga åtgärder eller nya integreringsmönster; inte alla funktioner behöver flaggor |
| Kanariedistribueringar | ✅ Affärskritiska ändringar släpps till små användarunderuppsättningar först (5-10% via behörighetsuppsättningar eller användarattributfiltrering); kanariefågelkohort övervakas intensivt 24-48 timmar för att mäta framgångsresultat, prestanda, felresultat innan lansering |
| Distributionsfönster | ✅ Distribueringar schemalagda under perioder med låg användning informeras av Event Monitoring API-användningsloggar som visar faktiska trafikmönster; undviker toppanvändning, månadsslut, kvartalsslut, större affärshändelser |
| Distributionskommunikation | ✅ Intressenter får förhandsmeddelande om distributionsfönster inklusive förväntad varaktighet, påverkad funktionalitet och tillbakadragande beslutstidslinje |
| Återställningsprocesser | ✅ Dokumenterade och testade återställningsprocesser för varje distributionstyp; teamet kan utföra återställning på under 30 minuter vid behov |
| Återställningstest | ✅ Återställningsprocesser validerade i icke-produktionsmiljö innan betydande distribueringar som säkerställer återställningskapacitet finns |
| Validering av distribuering | ✅ Röktester efter distribution validerar viktiga användarflöden, integreringsslutpunkter och nyckelfunktionalitet direkt efter utgivning |
| Ändringskoordination | ✅ Koordinerad distributionsstrategi när ändringar sträcker sig över flera system eller kräver synkroniserade utgåvor över Salesforce och externa plattformar |
| Övervaka under distribuering | ✅ Utökad övervakning aktiv under distributionsfönster och observationsperiod efter distribution (24-48 timmar) för att se felfrekvenstoppar, prestandaförsämring eller användarflödesfel |
| Blågrönt mönster för integreringar | ✅ Externa tjänster som frontar Salesforce använder blågröna distribueringar som upprätthåller två produktionsliknande miljöer, distribuerar till inaktiva först, växlar trafik efter validering |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Big Bang-distribueringar | ⚠️ Stora utgåvor som innehåller många funktioner, omfaktoriseringar och ändringar som distribueras samtidigt utan någon gradvis lansering; fel påverkar alla användare omedelbart |
| Driftsättningar under rusningstid | ⚠️ Releaser schemalagda under rusningstid (mitt på dagen, månadsslut, kvartalsslut) när användningen är som högst och användarpåverkan av problem maximeras |
| Ingen återställningsplan | ️ Distributioner fortsätter utan dokumenterade och testade återställningsprocesser; när problem uppstår krypterar teamet för att räkna ut återställning |
| Funktionen växlar som Eftertanke | ⚠️ Funktionsflagg som läggs till reaktivt när problem uppstår istället för att utformas proaktivt för ändringar med hög risk; begränsar tillbakadragandealternativ till fullständig distribuering |
| Ingen validering av distribuering | ⚠️ Ändringar distribuerade till produktion utan röktest efter distribution; teamet antar att distributionen lyckades och går vidare; problem som upptäcks timmar senare av användare |
| Otestade återföringsprocesser | ⚠️ Återställningsförfaranden dokumenterade men aldrig testade i icke-produktion; under den faktiska incidenten misslyckas förfarandet eller visar sig vara otillräckligt |
| Samtidiga ändringar av flera system | ️ Koordinerade ändringar i Salesforce och externa system distribuerade utan synkronisering eller kompabilitetstest; skapar integreringsfel |
| Ingen övervakningsförbättring | ️ Distributioner fortsätter utan utökad övervakning under distributionsfönstret; problem upptäcks genom användarklagomål istället för proaktiva varningar |
| Helgdistribueringar | ⚠️ Större utgåvor distribuerade fredag kväll eller helger när jourtäckningen är minskad och tillgängligheten för leverantörssupport begränsad |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Enhetstesttäckning | ✅ Meningsfull testomfattning validerar verksamhetsregler, kantfall, felvägar och styrande gränsmetod; överstiger avsevärt 75% minimikrav |
| Enhetstestkvalitet | ✅ Tester validerar verksamhetslogik, inte plattformsfunktionalitet; välskrivna enhetstester är snabba (millisekunder), isolerade (inget delat läge) och fokuserade (varje test validerar ett beteende) |
| Testa datastrategi | ✅ Tester använder @TestSetup-metoder för vanliga testdata; undvik SOQL-frågor i tester där så är möjligt; använd Test.loadData() för att läsa in statiska resurser |
| Håna externa beroenden | ✅ Enhetstester hånar externa anrop med hjälp av teststubbar och beroendeinjektion vilket möjliggör snabb körning utan faktiska HTTP-begäranden |
| Integreringstest | ✅ Validera interaktioner mellan utlösare, flöden, plattformshändelser, batchjobb och externa anrop som körs i sandboxar med representativa testdata |
| Tillförlitlighet för integreringstest | ✅ Integreringstester är repeterbara och deterministiska; sporadiska fel åtgärdas genom synkroniseringsmekanismer som repris-ID för plattformshändelser och batchjobbomröstning |
| Slut-till-slut-test | ✅ Automatiserade webbläsartester (Selenium, Playwright, Provar) validerar fullständiga användarresor för affärskritiska flöden som övar system genom användargränssnittet exakt när användare interagerar |
| E2E-testfokus | ✅ E2E-test fokuserar på användarsökvägar med högst värde på grund av långsammare utförande (minuter per test) och högre underhållsbörda från ändringar av användargränssnittet |
| Lasttest | ✅ Prestanda validerad under realistiska samtidiga användarinläsningar och datavolymer med hjälp av Salesforces belastningstesttjänster eller tredjepartsverktyg; avslöjar problem med styrande begränsningar, låsningstvister, prestandaförsämring |
| Belastningstestfrekvens | ✅ Belastningstester körs innan större utgåvor och regelbundet (kvartalsvis) för att validera prestanda vid 3x-5x nuvarande produktionsvolymer |
| Testpyramid | ✅ Balanserad testdistribution: många enhetstester (hundratals, minuter), färre integreringstester (dussin, minuter), få E2E-tester (under 20, minuter); snabb feedback vid basen, omfattande validering högst upp |
| Testisolering | ✅ Tester beror inte på varandra; kan köras i vilken ordning som helst; varje test lämnar systemet i rent tillstånd eller använder @TestSetup för enhetlig utgångspunkt |
| Negativa testfall | ✅ Tester validerar felhantering, valideringsregelverkställighet, behörighetsverkställighet och elegant försämring under ogynnsamma förhållanden |
| Test av styrande gräns | ✅ Tester validerar specifikt beteende som närmar sig styrande gränser inklusive SOQL-frågegränser, DML-gränser, CPU-tid, heapstorlek |
| Kontinuerligt testutförande | ✅ Tester körs automatiskt på varje överlämning via CI / CD-pipeline; misslyckade tester förhindrar distribution till högre miljöer |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Testa för täckning | ⚠️ Tester som skrivits enbart för att uppnå 75 % minimitäckning utan att validera verksamhetsregler eller kundcase; tester som inte bekräftar någonting eller testar triviala kodsökvägar |
| Testa plattformsfunktionalitet | ️ Tester validerar att Salesforce sparar poster eller SOQL-frågor fungerar istället för att validera verksamhetslogik; slösar ansträngning på plattformsgarantier |
| Ingen låtsasstrategi | ⚠️ Enhetstester gör faktiska anrop till externa system; testerna är långsamma, spröda till extern systemtillgänglighet och konsumerar API-gränser |
| Sporadiska testmisslyckanden | ⚠️ Tester godkänns eller misslyckas oförutsägbart baserat på körningstidpunkt, datastatus eller testkörningsordning; team lär sig ignorera misslyckanden och köra igen tills testerna godkänns |
| Inga integreringstester | ⚠️ Endast enhetstester finns; teamet validerar aldrig att utlösare, flöden, plattformshändelser och batchjobb fungerar tillsammans korrekt |
| Endast manuella E2E-tester | ⚠️ Kritiska användarflöden validerade manuellt innan varje utgåva; inga automatiserade E2E-test; regressioner upptäckta i produktion när manuella tester missar scenarion |
| Inga belastningstester | ⚠️ Prestanda validerad aldrig under realistiska samtidiga belastningar; problem med styrande begränsningar, låsning eller prestandaförsämring upptäckt i produktion |
| Testa databeroenden | ⚠️ Tester beror på specifika poster som finns i organisationen eller förutsätter en viss användarkonfiguration; bryts när sandboxen uppdateras eller konfigurationen ändras |
| Inga negativa testfall | ⚠️ Tester validerar endast lyckliga vägscenarier; testa aldrig felhantering, valideringstillämpning eller behörighetskontroller; fellägen oupptäckta |
| Överhoppade tester | ⚠️ Misslyckade tester kommenterade i @isTest och hoppade över istället för fixade; testsviten försämras med tiden när fler tester ignoreras |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Granska täckning | ✅ Alla produktionsbundna ändringar flödar genom kodgranskning via hämtningsbegäranden som kräver godkännande innan koppling; inkluderar Apex, Aura, LWC, Flöden, valideringsregler, behörighetsuppsättningar, delningsregler |
| Checklista för granskningskriterier | ✅ Explicit checklista som täcker säkerhet (CRUD / FLS tillämpning, validering av indata), prestanda (buntning, SOQL-optimering), styrande gränsefterlevnad (bearbetningsmönster, förebyggande av rekursion), underhållbarhet (namngivning, dokumentation, komplexitet), testtäckning (meningsfulla tester, kantfall), arkitektonisk enhetlighet (designmönster, separation av problem) |
| Granska storleksgränser | ✅ Hämta begäranden som hålls under 400 rader av meningsfulla ändringar som möjliggör noggrann granskning; stora funktioner uppdelade i mindre inkrementella ändringar som är individuellt granskningsbara och oberoende distribuerbara |
| Granska timing | ✅ Omdömen som slutförs inom en arbetsdag för att upprätthålla utvecklingstakten och ge snabb feedback; försenade granskningar skapar sammanhangsväxling |
| Automatiserade förhandsgranskningar | ✅ Statisk analys, enhetstester och säkerhetsskanning körs automatiskt innan mänsklig granskning begärs; automatiserade kontroller fångar mekaniska problem så att granskare fokuserar på design och verksamhetslogik |
| Ansvar för distribuerad granskning | ✅ Kodgranskningsansvar distribuerat över team för att förhindra flaskhalsar och dela Knowledge; yngre utvecklare granskar senior kod och förklarar sin egen kod under granskningar |
| Granska kvaliteten på kommentarer | ✅ Granskare ger specifik, åtgärdsbar feedback med motivering; skilja mellan obligatoriska ändringar (blockera problem) och förslag (trevligt att ha förbättringar) |
| Granska dokumentation | ✅ Hämta begäran beskrivningar förklarar vad som ändrats, varför det ändrades, vilka tester som gjordes, och alla speciella överväganden för distribution eller tillbakadragande förfaranden |
| Granskning av deklarativ konfiguration | ✅ Flöden, valideringsregler och behörighetsändringar får samma rigorösa granskning som kod; konfigurationen är arkitektonisk och förtjänar granskning |
| Uppföljning av kommentarer | ✅ Alla granskningskommentarer åtgärdade innan koppling; frågor besvarade, ändringar implementerade eller motivering till varför förslag inte antogs |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Ingen kodgranskning | ⚠️ Ändringar som gjorts direkt till produktionsgrenen utan någon inbördes granskning; eliminerar mekanismen för att upptäcka primära fel |
| Gummistämpling | ⚠️ Granskare godkänner hämtningsbegäranden inom några sekunder utan att faktiskt undersöka ändringar; granskning blir efterlevnad av kryssrutor istället för kvalitetsgrind |
| Flaskhals för enskild granskare | ⚠️ Endast en senior utvecklare auktoriserad att granska kod; skapar flaskhals och enskild felpunkt; Knowledge koncentrerad istället för distribuerad |
| Massiva hämtningsbegäranden | ⚠️ Hämta begäranden som innehåller tusentals rader av ändringar som sträcker sig över flera funktioner; omöjligt att granska noggrant vilket leder till ytlig undersökning |
| Försenade granskningar | ⚠️ Hämta begäranden ligger ogranskade i dagar eller veckor; utvecklare förlorar sammanhanget och flyttar till annat arbete; granskningskommentarer anländer när utvecklaren har bytt mentalt sammanhang |
| Inga granskningskriterier | ⚠️ Teamet saknar uttryckliga kriterier för vad granskare ska undersöka; granskningskvaliteten varierar kraftigt mellan granskare; vissa granskare fokuserar på stil, andra på logik, inga omfattande |
| Granska utan tester | ⚠️ Granskare godkänner endast ändringar baserat på kodinspektion utan att hämta gren och testa lokalt eller validera automatiserade tester |
| Ignorerade automatiska kontroller | ⚠️ Granskare godkänner hämtningsbegäranden trots misslyckad statisk analys, säkerhetsskanningar eller enhetstester; motverkar syftet med automatiserade kvalitetsgrindar |
| Fientlig granskningskultur | ⚠️ Recensioner blir personlig kritik eller tävlingsövning snarare än samarbete för kvalitetsförbättring; motverkar lärande och psykologisk säkerhet |
| Ingen deklarativ granskning | ⚠️ Flöden, valideringsregler, behörighetsuppsättningar och delningsregler distribueras utan granskning medan Apex kod granskas; skapar kvalitetsluckor i deklarativ konfiguration |