Operational Excellence - DevOps-mønstre
Lær mer om velbygd driftsutmerkelse → DevOps-rutiner
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Versjonskontrolloppsett | ✅ Alle metadata lagret i Git-kildeformat ved bruk av Salesforce DX prosjektstruktur med .forceignore konfigurert til å utelukke irrelevante filer; alle teammedlemmer klones fra sentralt repositorium |
| Bruk av midlertidig organisasjon | ✅ Utviklere oppretter midlertidige midlertidige organisasjoner fra kilden for funksjonsarbeid, bekrefter endringer tilbake til versjonskontroll og forkaster midlertidige organisasjoner etter at funksjonen er fullført |
| Bekreftelsesmeldinger | ✅ Hver bekreftelse inkluderer en tydelig og presis melding som forklarer hva som er endret og hvorfor. Meldinger følger teamkonvensjon (for eksempel “feat:”, “fix:”, “docs:“) |
| Endringssporing | ✅ Alle metadataendringer som fanges opp i versjonskontroll, med forfatteridentitet, tidsstempel og forskjell som viser eksakte endringer |
| Prosess for kodegjennomgang | ✅ Alle produksjonsbaserte endringer flyter gjennom henteforespørsler som krever gjennomgang av godkjenning før fletting, deklarativ konfigurasjon mottar samme kontroll som kode |
| Tilbakestillingsprosedyrer | ✅ Tidligere versjoner kan gjenopprettes fra Git-historikk gjennom Checkout eller tilbakestilling; teamet har dokumentert tilbakestillingsprosedyrer som er testet i ikke-produksjon |
| Revisjonsspor | ✅ Fullstendig endringshistorikk beholdt i versjonskontroll som støtter krav til samsvar og sikkerhetsundersøkelser |
| Forgreningsstrategi | ✅ Konsistent Git-forgreningsmodell (GitFlow, GitHub-flyt eller trunk-basert) egnet for teamstørrelse og utgivelsesfrekvens, dokumentert og håndhevet |
| Overføring fra organisasjonsbasert | ✅ Overgang til kildedrevet utvikling fullført tidlig i løsningens livssyklus før vaner blir solidgjort rundt organisasjonsbasert utvikling |
| .gitignore-konfigurasjon | ✅ Repositorium utelukker genererte filer, brukerspesifikke innstillinger og legitimasjon, inkluderer bare kildefiler som har tenkt å versjonere |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Organisasjon som sannhetskilde | ⚡️ Utvikling skjer direkte i delte Sandbox-organisasjoner med metadata eksportert til versjonskontroll etterpå, organisasjoner og versjonskontroll avviker og fører til distribusjonsfeil |
| Utilstrekkelig .gitignore | ⚡️ Repositorium inkluderer genererte filer, brukerspesifikke innstillinger, store binærfiler eller legitimasjon. Blåser opp repositoriet og risikerer sikkerhetsklargjøring |
| Vage bekreftelsesmeldinger | ⚡️ Forpliktelser som “rett opp feil” eller “oppdateringer” gir ingen kontekst for hva som er endret eller hvorfor, hindrer revisjonsundersøkelser og fremtidig vedlikehold |
| Store uvanlige bekreftelser | ⚡️ Utviklere bekrefter store endringssett ukentlig i stedet for små inkrementelle bekreftelser flere ganger daglig. Vanskelig å gjennomgå, vanskelig å isolere feil |
| Forpliktet direkte til hoved | ⚡️ Utviklere overfører endringer direkte til hovedforgreningen/produksjonsforgreningen ved å omgå gjennomgang og validering. |
| Ingen forgreningsstrategi | ⚡️ Teamet mangler en konsistent forgreningsmodell, utviklere oppretter vilkårlige forgreningenavn og flettemønstre, skaper forvirring og flettekonflikter |
| Binære filer i Git | ⚡️ Store binære filer (PDF-filer, videoer, arkiver) som er bekreftet til Git-oppblåst repositoriums størrelse og redusere hastigheten på kloneoperasjoner |
| Bekrefte legitimasjon | ⚡️ API-nøkler, passord, integrasjonslegitimasjon eller sikkerhetstokener som er bekreftet til versjonskontroll, oppretter sikkerhetssårbarhet selv etter fjerning fra senere bekreftelser |
| Ignorere sammenslåingskonflikter | ⚡️ Flettekonflikter løst ved å godta én side uten analyse, mister endringer eller introduserer feil |
| Ingen bekreftelse av forpliktelse | ⚡️ Teamet kontrollerer aldri at bekreftede metadata faktisk representerer tiltenkte endringer. Metadataformatfeil eller utilsiktede endringer glir gjennom |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Developer-Sandbox-organisasjoner | ✅ Individuelle utviklere bruker Developer-Sandbox-organisasjoner til funksjonsarbeid, enhetstesting og rask gjentagelse. Hver utvikler har et dedikert miljø |
| Developer Pro-Sandbox-organisasjoner | ✅ Team som utvikler administrerte pakker eller krever høyere lagringsgrenser, bruker Developer Pro-Sandbox-organisasjoner til samarbeid |
| Delvis kopi-Sandbox-organisasjoner | ✅ Integreringstesting bruker Delvis kopi-Sandbox-enheter med representative dataeksempler (10 000 poster per objekt) konfigurert via datamaler |
| Fullstendig kopi-Sandbox-organisasjoner | ✅ Ytelsestesting, produksjonslignende oppstillings- og dataoverføringsvalidering bruker Full kopi-Sandbox-enheter som inneholder fullstendige produksjonsdata og konfigurasjon |
| Datasensitivitetskontroller | ✅ Full Kopi Sandbox-tilgang begrenset til roller som krever produksjonsdata; Shield Platform Encryption datamasking brukt for ikke-produksjonsbruk når det er aktuelt |
| Konfigurasjon av integrasjonssluttpunkt | ✅ Hvert Sandbox-sjikt kobles til tilsvarende testendepunkter for eksterne integrasjoner. Produksjonsintegrasjoner kobles aldri til fra Sandbox-organisasjoner |
| Miljøspesifikk konfigurasjon | ✅ Integreringsarkitektur bruker tilpassede metadatatyper eller tilpassede innstillinger til å eksternalisere sluttpunkt-URL-adresser, legitimasjon og funksjonsflagg per miljø |
| Automatisering etter oppdatering | ✅ Sandbox-oppdateringer utløser automatiske Salesforce CLI som gjenoppretter Sandbox-spesifikke innstillinger, inkludert integrasjonslegitimasjon, testdatasammenføyning, funksjonsflaggstatuser og e-postlevering |
| Oppdatere planlegging | ✅ Sandbox-oppdateringsplan dokumentert og kommunisert, oppdateringer planlagt i perioder med lite aktivitet for å minimere teamavbrudd |
| Datamaler | ✅ Delvis kopi-Sandbox-enheter bruker velutformede datamaler som velger representative data på tvers av objekter og opprettholder referanseintegritet |
| Navngivingskonvensjoner | ✅ Sandbox-organisasjoner følger en tydelig navnekonvensjon som angir formål, eier og oppdateringssyklus (for eksempel “dev-integration-q2”, “uat-release-2-4”) |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Delt utvikling-Sandbox | ⚡️ Alle utviklere arbeider i én delt Sandbox-organisasjon og overskriver hverandres endringer. Det skaper forvirring om hva som er distribuerbar status |
| Foreldede Sandbox-organisasjoner | ⚡️ Sandbox-organisasjoner som ikke har blitt oppdatert i måneder, avviker betydelig fra produksjonskonfigurasjonen. Testing i ikke-representative miljøer fører til distribusjonsfeil |
| Ingen datastyring i full kopi | ⚡️ Full kopi-Sandbox-organisasjoner som inneholder produksjons-PII, økonomiske data og HIPAA-data som er tilgjengelig for hele utviklingsteamet uten tilgangskontroller eller datamaskering |
| Produksjonsintegrasjoner fra Sandbox | ⚡️ Sandbox-organisasjoner kobler direkte til produksjonsintegreringssluttpunkter og skaper risiko for testtransaksjoner som påvirker produksjonsdata eller eksterne systemer |
| Manuell konfigurasjon etter oppdatering | ⚡️ Sandbox-oppdateringer krever timer med manuell gjenoppretting av gjenopprettingsinnstillinger. Overhead fraråder oppdatering av Sandbox-organisasjoner så ofte som nødvendig |
| Ingen Sandbox-dokumentasjon | ⚡️ Teamet mangler dokumentasjon om Sandbox-formål, oppdateringsplaner, datainnhold eller tilgangsprosedyrer. Utviklere gjetter hvilket miljø som skal brukes til hvilket formål |
| Enkel miljøtype | ⚡️ Teamet bruker bare én Sandbox-type (vanligvis Developer eller Full Copy) til alle formål, mangler fordeler med riktig Sandbox-strategi per aktivitet |
| Sandbox-lager | ⚡️ Sandbox-organisasjoner som er tildelt enkeltpersoner eller prosjekter og aldri er utgitt når de ikke lenger er nødvendige; kunstig manko på tross av tilgjengelige lisenser |
| Utilstrekkelige testdata | ⚡️ Testdata i Sandbox-organisasjoner representerer ikke produksjonsdataegenskaper (volumer, relasjoner, kanttilfeller); testing i urealistiske miljøer mangler produksjonsproblemer |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Kildeforpliktelsesfase | ✅ Utviklere bekrefter endringer i funksjonsforgrener i Git med tydelige bekreftelsesmeldinger som forklarer kontekst og grunnlag |
| Fase for statisk analyse | ✅ Salesforce Code Analyzer skanner Apex for sikkerhetssårbarheter (OWASP Top 10), ytelsesmotmønstre (SOQL i sløyfer, DML i sløyfer), kodekvalitetsproblemer (kompleksitet, duplisering) og styringsgrenser, kjører på sekunder og gir umiddelbar tilbakemelding |
| Enhetstestfase | ✅ Apex utfører validering av forretningslogikk og styringsgrensesamsvar i midlertidig midlertidig organisasjon eller dedikert integrasjons-Sandbox-organisasjon, riktig isolerte tester fullføres på under 5 minutter |
| Valideringsdistribusjonsfase | ✅ Metadata distribueres til integrasjons-Sandbox med Salesforce CLI med –checkonly-flagg for valideringsbare distribusjonstester uten å utføre endringer |
| Testfase for integrasjon | ✅ Automatiserte tester validerer arbeidsflyter med flere komponenter, eksterne integrasjonskontrakter, plattformhendelsesflyter og asynkrone behandlingskjeder mot felles integrasjonsmiljø med testdatabehandling |
| Sikkerhetsskanningsfase | ✅ Ekstra sikkerhetsverktøy skanner for hardkodede legitimasjoner, sårbare avhengigheter, CRUD/FLS-brudd og overtredelser av samsvarspolicyer; viktige funn brytes |
| UAT-distribusjonsfase | ✅ Endringer som overføres alle automatiserte porter distribueres til et brukerakseptansetestmiljø for forretningsvalidering. Distribusjon kan være automatisert eller kreve manuell godkjenning basert på endringsrisiko |
| Distribusjonsfase for produksjon | ✅ Etter UAT-godkjenning distribueres endringer til produksjon med automatisert utførelse med ett klikk, omfattende logging og umiddelbar tilbakekalling |
| Pipeline Execution Time (Utførelsestid for pågående arbeid) | ✅ End-to-end pipeline fullføres på under 15 minutter for typiske endringer som aktiverer rask tilbakemelding, lengre for store distribusjoner eller omfattende testpakker |
| Bygge artefakter | ✅ Pipeline beholder distribusjonspakker, testresultater, sikkerhetsskanningsrapporter og utførelseslogger for overholdelse og feilsøking |
| Pipeline Tooling (Verktøy for pågående arbeid) | ✅ Team bruker Salesforce DevOps Center for plattformbasert CI/CD, eller integrere med eksterne plattformer (GitHub Actions, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Feilvarsler | ✅ Pipeline-feil utløser varsler om å bekrefte forfatter og relevante kanaler med diagnostisk kontekst som aktiverer rask rettelse |
| Grenbeskyttelse | ✅ Hoved- og produksjonsforgrener beskyttet som krever CI-kontroller og godkjente vurderinger før fletting, direkte bekreftelser hindret |
| Miljøpromotering | ✅ Endringer flyter gjennom definert promoteringsbane (dev → integrasjon → UAT → produksjon) med validering i hver fase |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Manuelle distribusjoner | ⚡️ Endringer som distribueres manuelt via endringssett eller Salesforce CLI med inkonsekvente trinn, feil fra person, manglende trinn, manglende revisjonsspor |
| Ingen statisk analyse | ⚡️ Pipelines hopper over Salesforce Code Analyzer eller lignende verktøy, sikkerhetssårbarheter, ytelsesmønstre, kodekvalitetsproblemer når produksjonsorganisasjonen |
| Ikke tilstrekkelig testing | ⚡️ Pipeline validerer bare minimum 75 % dekning uten å kjøre integreringstester eller validere viktige brukerflyter. |
| Ingen sikkerhetsskanning | ⚡️ Pipelines skanner aldri etter hardkodede legitimasjoner, sårbare avhengigheter eller CRUD/FLS-brudd. Sikkerhetsproblemer oppdaget i produksjons- eller sikkerhetsgjennomganger |
| Utførelse av langsom pipeline | ⚡️ Slutt-til-slutt under arbeid tar 45-60+ minutter, noe som hindrer hyppige bekreftelser og reduserer hastigheten på tilbakemeldingsløyfer. Utviklere forplikter seg mindre ofte og akkumulerer større endringer |
| Ignorerte pipelinefeil | ⚡️ Team ignorerer eller overstyrer pipelinefeil for å oppfylle tidsfrister. Kvalitetsportaler blir teater i stedet for faktiske kontroller |
| Ingen testmiljøparitet | ⚡️ CI/CD valideres i miljø med forskjellig konfigurasjon, grenser eller datakarakteristikker enn produksjon. Overføring av validering garanterer ikke produksjonsytelse |
| Mangler tilbagerulingsmulighet | ⚡️ Pipeline automatiserer distribusjon, men gir ingen automatisk tilbakekalling. Gjenoppretting fra feil distribusjon krever manuelle hasteprosedyrer |
| Ingen distribusjonslogger | ⚡️ Distribusjoner utført uten omfattende logging, feilsøking eller revisjon av distribusjoner blir vanskelig |
| Testing av alt eller ingenting | ⚡️ Pipeline kjører alle tester for hver endring uavhengig av hva som er endret. 30-minutters testpakke kjører også for dokumentasjonsoppdateringer |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Funksjonsflagg | ✅ Høy risiko-endringer distribueres med funksjoner som er deaktivert bak tilpasset metadatatype eller konfigurasjon av tilpassede innstillinger. Aktiverer testing i produksjon uten brukereksponering, gradvis utrulling til segmenter, A/B-testing og umiddelbar tilbakekalling via konfigurasjonsendring |
| Funksjonsflagg-omfang | ✅ Funksjonsflagg reservert for endringer med høy risiko som påvirker viktige forretningsprosesser, ytelsessensitive operasjoner eller nye integrasjonsmønstre. Ikke alle funksjoner trenger flagg |
| Kanarie distribusjoner | ✅ Forretningskritiske endringer frigis til små brukerdelsett først (5-10 % via tillatelsessett eller brukerattributtfiltrering); kanarisk kohorte overvåkes intensivt 24-48 timer for å måle suksessfrekvenser, ytelse og feilfrekvenser før utrulling utvides |
| Distribusjonsvinduer | ✅ Distribusjoner som er planlagt i perioder med lav bruk, informert av Event Monitoring API-brukslogger som viser faktiske trafikkmønstre, unngår bruk av høydepunkter, avslutning på månedsslutt, avslutning på kvartalsslutt og viktige forretningshendelser |
| Distribusjonskommunikasjon | ✅ Interessenter mottar forhåndsvarsel om distribusjonsvinduer, inkludert forventet varighet, påvirket funksjonalitet og tidslinje for tilbakeføringsbeslutninger |
| Tilbakestillingsprosedyrer | ✅ Dokumenterte og testede tilbakemeldingsprosedyrer for hver distribusjonstype. Teamet kan utføre tilbakemelding på under 30 minutter når det er nødvendig |
| Tilbaketesting | ✅ Tilbakemeldingsprosedyrer som er validert i et ikke-produksjonsmiljø før betydelige distribusjoner som sikrer gjenopprettingsmulighet |
| Distribusjonsvalidering | ✅ Røketester etter distribusjon validerer viktige brukerflyter, integrasjonssluttpunkter og nøkkelfunksjonalitet umiddelbart etter utgivelsen |
| Endre koordinasjon | ✅ Koordinert distribusjonsstrategi når endringer spenner over flere systemer eller krever synkroniserte utgivelser på tvers av Salesforce og eksterne plattformer |
| Overvåke under distribusjon | ✅ Forbedret overvåking aktiv i distribusjonsvinduet og i observasjonsperioden etter distribusjon (24-48 timer) for å se etter høyere feilfrekvens, nedgang i ytelse eller feil i brukerflyter |
| Blått-grønt mønster for integrasjoner | ✅ Eksterne tjenester som bruker Salesforce, bruker blå-grønne distribusjoner som opprettholder to produksjonslignende miljøer, distribuerer til inaktiv først, bytter trafikk etter validering |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Big Bang-distribusjoner | ⚡️ Store utgivelser som inneholder mange funksjoner, ombygginger og endringer distribuert samtidig uten gradvis utrulling. Feil påvirker alle brukere umiddelbart |
| Distribusjoner for høytid | ⚡️ Utgivelser som er planlagt i åpningstider (middagen, månedsslutt, kvartalsslutt) når bruken er høyest og brukerinnvirkningen av problemer er maksimert |
| Ingen tilbagerulingsplan | ⚡️ Distribusjoner fortsetter uten dokumenterte og testede tilbakeføringsprosedyrer. Når problemer dukker opp, går teamet rundt for å finne ut hvordan de kan gjenopprettes |
| Funksjonsbryter som ettertanke | Funksjonsflagg legges til aktivt når problemer oppstår i stedet for å utformes proaktivt for endringer med høy risiko. Begrenser alternativer for tilbakemelding til full tilbakestilling av distribusjon |
| Ingen distribusjonsvalidering | ⚡️ Endringer distribuert til produksjon uten røketester etter distribusjon, teamet forutsetter at distribusjonen var vellykket og fortsetter, problemer oppdaget timer senere av brukere |
| Ikke-testede tilbakeføringsprosedyrer | ⚡️ Tilbakemeldingsprosedyrer dokumentert, men aldri testet i ikke-produksjon. Under faktisk hendelse mislykkes prosedyren eller viser seg utilstrekkelig |
| Samtidig endring av flere systemer | ⚡️ Koordinerte endringer på tvers av Salesforce og eksterne systemer distribuert uten synkronisering eller kompatibilitetstesting. |
| Ingen overvåking av forbedring | ⚡️ Distribusjoner fortsetter uten forbedret overvåking under distribusjonsvinduet, problemer oppdages via brukerklager i stedet for proaktive varsler |
| Weekenddistribusjoner | ⚡️ Viktige utgivelser distribuert fredag kveld eller helger når dekning ved oppringing er redusert og leverandørstøtte er begrenset |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Unit Test Coverage (Enhetsdekning) | ✅ Betydelig testdekning som validerer forretningsregler, kanttilfeller, feilbaner og styringsgrense-tilnærming, betydelig overskrider minimumskravet på 75 % |
| Enhetstestkvalitet | ✅ Tester validerer forretningslogikk, ikke plattformfunksjonalitet. Velskrevne enhetstester er raske (millisekunder), isolerte (ingen delt status) og fokuserte (hver test validerer én virkemåte) |
| Testdatastrategi | ✅ Tester bruker @TestSetup-metoder til vanlige testdata, unngå SOQL-spørringer i tester der det er mulig, og bruk Test.loadData() til å laste inn statiske ressurser |
| Mock External Dependencies (Mock Eksterne avhengigheter) | ✅ Enhetstester mock eksterne oppkall ved bruk av teststubs og avhengighetsinnsetting som aktiverer rask utførelse uten faktiske HTTP-forespørsler |
| Integreringstester | ✅ Valider interaksjoner mellom utløsere, flyter, plattformhendelser, gruppejobber og eksterne oppkall som kjører i Sandbox-organisasjoner, med representative testdata |
| Integreringstestens pålitelighet | ✅ Integreringstester er gjentagende og deterministiske. Sporadiske feil løses via synkroniseringsmekanismer som plattformhendelsesrepetisjons-IDer og gruppejobbspørring |
| Slutt-til-slutt-tester | ✅ Automatisert nettlesertesting (Selenium, Playwright, Provar) validerer fullstendige brukerreiser for forretningskritiske flyter ved å utøve systemet via grensesnittet nøyaktig slik brukere samhandler |
| E2E-testfokus | ✅ E2E-tester fokuserer på brukerbaner med høyeste verdi på grunn av langsommere utførelse (minutter per test) og høyere vedlikeholdsbelastning fra grensesnittendringer |
| Innlastingstesting | ✅ Ytelse validert under realistiske samtidige brukerbelastninger og datavolumer ved bruk av Salesforce Load Testing-tjenester eller tredjeparts verktøy; viser problemer med styringsgrenser, låsingskonflikter, ytelsesreduksjon |
| Innlastingstestfrekvens | ✅ Innlastingstester kjøres før hovedutgivelser og regelmessig (kvartalsvis) for å validere ytelse ved 3x-5x gjeldende produksjonsvolumer |
| Test pyramide | ✅ Balansert testfordeling: mange enhetstester (hundrevis, minutter), færre integreringstester (doser, minutter), få E2E-tester (under 20 minutter); rask tilbakemelding på grunnlaget, omfattende validering øverst |
| Testisolering | ✅ Tester er ikke avhengige av hverandre, kan kjøres i hvilken som helst rekkefølge. Hver test forlater systemet i ren tilstand eller bruker @TestSetup som konsistent startpunkt |
| Negative testtilfeller | ✅ Tester validerer feilhåndtering, håndheving av valideringsregler, håndheving av tillatelser og god nedgang under ugunstige forhold |
| Kontroll av styringsgrense | ✅ Tester validerer spesielt virkemåte som nærmer seg styringsgrenser, inkludert SOQL-spørringsgrenser, DML-grenser, CPU-tid, heap-størrelse |
| Utførelse av kontinuerlig testing | ✅ Tester kjøres automatisk på hver bekreftelse via CI/CD under behandling. Mislykkede tester hindrer distribusjon til høyere miljøer |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Teste for dekning | ⚡️ Tester skrevet utelukkende for å oppnå minimum dekning på 75 % uten å validere forretningsregler eller kanttilfeller, tester som ikke angir noe eller tester banale kodebaner |
| Teste plattformfunksjonalitet | ⚡️ Tester validerer at Salesforce lagrer poster eller SOQL-spørringer fungerer i stedet for å validere forretningslogikk. |
| Ingen mock-strategi | ⚡️ Enhetstester gjør faktiske oppkall til eksterne systemer. Testene er trege, skjøre for tilgjengelighet av eksterne systemer og bruker API-grenser |
| Sporadiske testfeil | ⚡️ Tester passerer eller mislykkes uforutsigbart basert på utførelsestidspunkt, datatilstand eller testutførelsesrekkefølge. Team lærer å ignorere feil og kjører på nytt til testene passerer |
| Ingen integreringstesting | ⚡️ Bare enhetstester finnes. Teamet validerer aldri om utløsere, flyter, plattformhendelser og gruppejobber fungerer sammen riktig |
| Bare manuell E2E-testing | ⚡️ Kritiske brukerflyter validert manuelt før hver utgivelse, ingen automatiserte E2E-tester, regresjoner oppdaget i produksjon når manuell testing går glipp av scenarier |
| Ingen innlastingstesting | ⚡️ Ytelse som aldri er validert under realistiske samtidige belastninger, styringsgrenseproblemer, låsekonflikter eller ytelsesreduksjon oppdaget i produksjon |
| Teste dataavhengigheter | ⚡️ Tester er avhengig av bestemte poster som finnes i organisasjonen, eller forutsetter en bestemt brukerkonfigurasjon. Avbrudd når Sandbox-organisasjonen oppdateres eller konfigurasjonen endres |
| Ingen negative testtilfeller | ⚡️ Tester validerer bare tilfredsstilte banescenarier, tester aldri feilhåndtering, valideringshåndhevelse eller tillatelsessjekker, feilmoduser blir ikke oppdaget |
| Hoppede tester | ⚡️ Mislykkede tester kommentert utenfor @isTest og hoppet over i stedet for fast; testpakken reduseres over tid etter hvert som flere tester ignoreres |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Se gjennom dekning | ✅ Alle produksjonsbaserte endringer flyter gjennom kodegjennomgang via henteforespørsler som krever godkjenning før fletting, inkludert Apex, Aura, LWC, flyter, valideringsregler, tillatelsessett, delingsregler |
| Sjekkliste for gjennomgangskriterier | ✅ Eksplisitt sjekkliste som dekker sikkerhet (CRUD/FLS-håndhevelse, inndatavalidering), ytelse (bulkifisering, SOQL-optimalisering), overholdelse av styringsgrenser (behandlingsmønstre, forhindring av rekursjon), vedlikehold (navngiving, dokumentasjon, kompleksitet), testdekning (betydelige tester, kanttilfeller), arkitektonisk konsistens (utformingsmønstre, separasjon av bekymringer) |
| Se gjennom størrelsesgrenser | ✅ Pull-forespørsler beholdt under 400 linjer med meningsfylte endringer som muliggjør grundig gjennomgang, store funksjoner delt inn i mindre trinnvise endringer som kan gjennomgås individuelt og distribueres uavhengig |
| Se gjennom tidsplan | ✅ Gjennomganger som er fullført innen én arbeidsdag, opprettholder utviklingsdynamikk og gir rask tilbakemelding. Forsinkede gjennomganger oppretter kontekstbytte overhead |
| Automatiske forhåndsgjennomgangskontroller | ✅ Statiske analyser, enhetstester og sikkerhetssøk kjøres automatisk før den personlige gjennomgangen forespørres. Automatiske kontroller fanger opp mekaniske problemer slik at de som gjennomgår, fokuserer på design og forretningslogikk |
| Forpliktelse for distribuert gjennomgang | ✅ Ansvar for kodegjennomgang fordelt på team for å hindre flaskehalser og dele Knowledge; juniorutviklere gjennomgår seniorkode og forklarer sin egen kode under gjennomgangene |
| Gjennomgå kvalitet på kommentarer | ✅ Gjennomgangere gir spesifikk tilbakemelding som kan handles på, med grunnlag. Skill mellom nødvendige endringer (blokkeringsproblemer) og forslag (forbedringer som er gode å ha) |
| Se gjennom dokumentasjon | ✅ Beskrivelser av henteforespørsler forklarer hva som ble endret, hvorfor det ble endret, hvilke tester som ble utført, og eventuelle spesielle viktige punkter om distribusjon eller tilbakeføringsprosedyrer |
| Gjennomgang av deklarasjonskonfigurasjon | ✅ Flyter, valideringsregler og tillatelsesendringer får samme gjennomgangstrekk som kode. Konfigurasjonen er arkitektonisk og fortjener gjennomgang |
| Oppfølging av kommentarer | ✅ Alle gjennomgangskommentarer som ble tatt opp før fletting, besvarte spørsmål, implementerte endringer eller begrunnelse for hvorfor forslaget ikke ble tatt i bruk |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Ingen kodegjennomgang | ⚡️ Endringer som utføres direkte i produksjonsavdelingen uten fagfellevurdering, eliminerer primær defektdeteksjonsmekanisme |
| Stempel på gummi | ⚡️ Gjennomgangere godkjenner henteforespørsler innen sekunder uten faktisk å undersøke endringer. Gjennomgang blir avmerkingsboksesamsvar i stedet for kvalitetsport |
| Bottleneck for enkeltbruker | ⚡️ Bare én seniorutvikler autorisert til å gjennomgå kode; skaper flaskehals og enkelt feilpunkt; Knowledge konsentrert i stedet for distribuert |
| Massevise henteforespørsler | ⚡️ Henteforespørsler som inneholder tusenvis av linjer med endringer som spenner over flere funksjoner, umulig å gjennomgå grundig, noe som fører til overfladisk undersøkelse |
| Forsinkede vurderinger | ⚡️ Pull-forespørsler sitter ikke gjennomgått i dager eller uker, utviklere mister kontekst og flytter til annet arbeid, gjennomgangskommentarer kommer når utvikleren har byttet mental kontekst |
| Ingen gjennomgangskriterier | ⚡️ Teamet mangler eksplisitte kriterier for hva de som gjennomgår, bør undersøke. Gjennomgangskvaliteten varierer sterkt etter den som gjennomgår, noen gjennomgår fokus på stil, andre på logikk, ingen omfattende |
| Se gjennom uten testing | ⚡️ Gjennomgangere godkjenner endringer basert på kodeinspeksjon alene uten å trekke ut gren og teste lokalt eller validere automatiske tester |
| Ignorerte automatiske kontroller | ⚡️ Gjennomgangere godkjenner henteforespørsler til tross for mislykkede statiske analyser, sikkerhetsskanninger eller enhetstester. |
| Kultur for fiendtlig gjennomgang | ⚡️ Gjennomganger blir personlig kritikk eller konkurransedyktige øvelser i stedet for forbedring av samarbeidskvalitet. Avskrekker læring og psykologisk sikkerhet |
| Ingen deklarasjonsgjennomgang | ⚡️ Flyter, valideringsregler, tillatelsessett og delingsregler distribueres uten gjennomgang mens Apex blir kontrollert. Oppretter kvalitetshull i deklarativ konfigurasjon |