Operational Excellence - DevOps-kuviot
Lue lisää Hyvin rakennettujen toimintojen parantamisesta → DevOps-käytännöt
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Version hallinnan määritykset | ✅ Kaikki Git-lähdemuodossa säilytetty metadata käyttämällä Salesforce DX -projektin rakennetta, jossa .forceignore on määritetty jättämään pois asiaankuuluvat tiedostot; kaikki tiimin jäsenet kloonataan keskitetystä säilöstä |
| Luonnosorganisaation käyttö | ✅ Kehittäjät luovat epävakaita luonnosorganisaatioita lähteestä ominaisuuden töille, sitouttavat muutokset takaisin versioiden hallintaan ja hylkäävät luonnosorganisaatiot ominaisuuden suorittamisen jälkeen |
| Vähimmäissumman viestit | ✅ Jokainen sitoumus sisältää selkeän ja ytimekkään viestin, joka selittää muutokset ja syyn. Viestit noudattavat tiimin käytäntöjä (esimerkiksi “feat:”, “fix:”, “docs:“) |
| Muutosten seuranta | ✅ Kaikki version hallinnassa kaapatut metadatan muokkaukset, joissa näytetään tekijän henkilöllisyys, aikaleima ja diff-arvo, jotka näyttävät tarkat muutokset |
| Koodin tarkastusprosessi | ✅ Kaikki tuotantoon liittyvät muutokset kulkevat noutopyyntöjen läpi, jotka vaativat hyväksynnän tarkastuksen ennen yhdistämistä; deklaratiivinen kokoonpano saa saman tarkastuksen kuin koodi |
| Periytymistoimenpiteet | ✅ Aiemmat versiot voidaan palauttaa Git-historiasta Checkout tai revert-toiminnoilla; tiimillä on dokumentoitu periytymismenetelmiä, joita testattiin muussa kuin tuotantoympäristössä |
| Kirjausketju | ✅ Muutoshistoria säilytetään versioiden hallinnassa, joka tukee vaatimustenmukaisuuden vaatimuksia ja tietoturvatutkimuksia |
| Haarausstrategia | ✅ Tiimin koon ja julkaisutiheyden mukainen yhdenmukainen Git-haarautumismalli (GitFlow, GitHub-kulku tai säiliöön perustuva) dokumentoitu ja käytössä |
| Siirtyminen organisaatioihin perustuvasta | ✅ Siirry lähdepohjaiseen kehitykseen, joka on suoritettu ratkaisun elinkaaren alussa ennen kuin tavat vahvistuvat organisaatioihin perustuvan kehityksen ympärille |
| .gitignore-kokoonpano | ✅ Säiliö ei sisällä luotuja tiedostoja, käyttäjäkohtaisia asetuksia ja tunnuksia. Sisältää vain lähdetiedostot, jotka tiimit aikovat versioida |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Organisaatio totuuden lähteenä | ⚡️ Kehitys tapahtuu suoraan jaetuissa sandboxeissa, kun metadata viedään versioiden hallintaan sen jälkeen; organisaatiot ja versioiden hallinta eroavat toisistaan, mikä aiheuttaa käyttöönottovirheitä |
| Riittämätön .gitignore | ⚡️ Säiliö sisältää luodut tiedostot, käyttäjäkohtaiset asetukset, suuret binaarit tai tunnukset; täyttää säiliön ja aiheuttaa tietoturvariskin |
| Epätarkka sitoutusviesti | ⚡️ Sitoumukset, kuten “korjaa virhe” tai “päivitykset”, eivät tarjoa tietoja siitä, mikä muuttui tai miksi; haittaa tarkastusten tutkimista ja tulevia ylläpitotoimia |
| Suuret harvinaiset sitoumukset | ⚡️ Kehittäjät sitouttavat suuria muutosjoukkoja viikoittain pienien asteittaisten sitoumusten sijaan useita kertoja päivässä. Vaikea tarkastaa, vaikea eristää virheitä |
| Sitoudu suoraan päätietueeseen | ⚡️ Kehittäjät siirtävät muutokset suoraan pää- ja tuotanto-haaralle ohittaakseen tarkastuksen ja vahvistuksen. |
| Ei haarautumisstrategiaa | ⚡️ Tiimillä ei ole yhdenmukaista haarautumismallia; kehittäjät luovat satunnaisia haarojen nimiä ja yhdistämiskuvioita; aiheuttaa sekaannusta ja yhdistämisristiriitoja |
| Binääritiedostot Gitissä | ⚡️ Suuria binääritiedostoja (PDF-tiedostoja, videoita, arkistoja), jotka on sitoutunut Git-säiliön kasvattamaan kokoaan ja hidastamaan kloonaustoimintoja |
| Tunnusten sitouttaminen | ⚡️ API-avaimet, salasanat, integraatiotunnukset tai suojausvaltuudet, jotka on sitoutettu versioiden hallintaan; luo suojaushaavoittuvuuden, vaikka ne poistettaisiin myöhemmistä sitoutuksista |
| Yhdistämisristiriitojen ohittaminen | ⚡️ Ratkaisee ristiriidat hyväksymällä yksi sivu ilman analyysiä; häviää muutokset tai tuo virheet |
| Ei sitoumuksen vahvistusta | ⚡️ Tiimi ei koskaan vahvista, että sitoutunut metadata edustaa todellisuudessa tarkoitettuja muutoksia. Metadatamuotojen virheet tai tahattomat muutokset läpäisevät |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Developer-sandboxit | ✅ Yksittäiset kehittäjät käyttävät Developer-sandboxeja ominaisuuksien töihin, yksikkötesteihin ja pikaiseen iterointiin. Jokaisella kehittäjällä on oma ympäristö |
| Developer Pro -sandboxit | ✅ Hallittuja paketteja kehittävät tai korkeampia tallennusrajoituksia vaativat tiimit käyttävät Developer Pro -sandboxeja yhteistyöhön |
| Partial Copy -sandboxit | ✅ Integraatiotestit käyttävät Partial Copy -sandboxeja, joissa on edustavia datamalleja (10 000 tietuetta per objekti) määritettynä datamallien kautta |
| Full Copy -sandboxit | ✅ Suorituskyvyn testaaminen, tuotantoympäristöön perustuva vaiheistaminen ja datan siirron vahvistus käyttävät Full Copy -sandboxeja, jotka sisältävät koko tuotantotiedot ja kokoonpanot |
| Datan luottamuksellisuuden ohjaimet | ✅ Full Copy -sandbox-käyttöoikeus rajoitettu rooleihin, jotka vaativat tuotantotietoja; Shield Platform Encryption -datan peittämistä sovelletaan tarvittaessa muuhun kuin tuotantoympäristöön |
| Integraation päätepisteen kokoonpano | ✅ Jokainen sandbox-taso muodostaa yhteyden vastaaviin testipäätepisteisiin ulkoisia integraatioita varten; tuotanto-integraatiot eivät koskaan muodosta yhteyttä sandboxeista |
| Ympäristökohtainen kokoonpano | ✅ Integrointiarkkitehtuuri käyttää mukautettuja metadatatyyppejä tai mukautettuja asetuksia ulkoistaakseen päätepisteiden URL-osoitteita, tunnuksia ja ominaisuusmerkintöjä per ympäristö |
| Päivityksen jälkeinen automatisointi | ✅ Sandboxien päivitykset käynnistävät automatisoituja Salesforce CLI -komentosarjoja, jotka palauttavat sandbox-kohtaisia asetuksia, mukaan lukien integrointitunnukset, testitietojen kylvö, ominaisuuksien lippujen tilat ja sähköpostin toimituskyvyn |
| Päivitysaikataulu | ✅ Sandboxien päivitysaikataulu on dokumentoitu ja ilmoitettu; päivitykset on suunniteltu vähäisen aktiivisuuden aikana tiimin häiriöiden välttämiseksi |
| Datamallit | ✅ Partial Copy -sandboxit käyttävät hyvin suunniteltuja datamalleja, jotka valitsevat edustavaa dataa kaikista objekteista ja ylläpitävät viitteellistä eheyttä |
| Nimeämiskäytännöt | ✅ Sandboxit noudattavat selkeää nimeämiskäytäntöä, joka osoittaa käyttötarkoituksen, omistajan ja päivityssyklin (esimerkiksi “dev-integration-q2”, “uat-release-2-4”) |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Jaettu kehitys -sandbox | ⚡️ Kaikki kehittäjät työskentelevät yhdessä jaetussa sandboxissa korvaamalla toistensa muutokset; aiheuttaa hämmennystä siitä, mikä on käyttöönotettava tila |
| Vanhentuneet sandboxit | ⚡️ Sandboxit, joita ei ole päivitetty kuukausien aikana, eroavat merkittävästi tuotantokokoonpanosta; testaaminen ei-representatiivisessa ympäristössä johtaa käyttöönottovirheisiin |
| Ei datan hallintaa kokonaan | ⚡️ Full Copy -sandboxit, jotka sisältävät tuotanto-tietojen henkilötietoja, taloustietoja ja HIPAA-tietoja, joita koko kehitystiimi voi käyttää ilman käyttöoikeuksien hallintaa tai datan peittämistä |
| Tuotanto-integraatiot sandboxista | ⚡️ Sandboxit muodostavat yhteyden suoraan tuotanto-integraation päätepisteisiin, mikä aiheuttaa riskin, että testitransaktiot vaikuttavat tuotanto-dataan tai ulkoisiin järjestelmiin |
| Manuaalinen päivityksen jälkeinen kokoonpano | ⚡️ Sandboxien päivitykset vaativat tunteja manuaalista konfigurointia asetusten palauttamiseksi. Overhead estää sandboxien päivittämisen tarvittaessa |
| Ei sandbox-dokumentaatiota | ⚡️ Tiimillä ei ole dokumentaatiota sandbox-tarkoituksista, päivitysaikatauluista, datan sisällöstä tai käyttöoikeustoimenpiteistä. Kehittäjät arvaavat, mitä ympäristöä käytetään mihin tarkoitukseen |
| Yksi ympäristötyyppi | ⚡️ Tiimi käyttää kaikissa käyttötarkoituksissa vain yhtä sandbox-tyyppiä (tavallisesti Developer tai Full Copy); se ei hyödytä asiaankuuluvaa sandbox-strategiaa per toiminto |
| Sandboxien kerääminen | ⚡️ Yksityishenkilöille tai projekteille kohdistetut sandboxit, joita ei koskaan julkaista, kun niitä ei enää tarvita; keinotekoinen puute saatavilla olevista lisensseistä huolimatta |
| Riittämättömät testitiedot | ⚡️ Sandboxeissa olevat testitiedot eivät edusta tuotantotietojen ominaisuuksia (määrät, suhteet, ääriviivat); testaaminen epärealistisessa ympäristössä ohittaa tuotanto-ongelmat |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Lähteen sitoutumisvaihe | ✅ Kehittäjät sitouttavat muutoksia ominaisuuksien haaroihin Gitissä selkeillä sitoutusviesteillä, jotka selittävät asiayhteyden ja syyn |
| Staattisen analyysin vaihe | ✅ Salesforce Code Analyzer skannaa Apexin tietoturvariskien varalta (OWASP Top 10), suorituskyvyn vastaiset kuviot (SOQL silmukoissa, DML silmukoissa), koodin laatuongelmat (monimutkaisuus, identtisyys) ja hallintorajoitukset; suoritetaan sekunteina välittömästi palautetta varten |
| Yksikön testin vaihe | ✅ Apex suorittavat liiketoimintalogiikan vahvistuksen ja hallintorajoituksen vaatimustenmukaisuuden väliaikaisessa luonnosorganisaatiossa tai erillisessä integraatiosandboxissa; asianmukaisesti eristetyt testit suoritetaan alle 5 minuutissa |
| Vahvistuksen käyttöönoton vaihe | ✅ Metadata otetaan käyttöön integraation sandboxiin käyttämällä Salesforce CLI -tiedostoa –checkonly-merkinnällä vain vahvistus -käyttöönoton suoritettavia testejä tekemättä muutoksia |
| Integroinnin testin vaihe | ✅ Automatisoidut testit vahvistavat monikomponenttityönkulut, ulkoiset integraatiosopimukset, sovellusalustan tapahtumien kulut ja asynkroniset käsittelyketjut jaetun integraatioympäristön kanssa testitietojen hallinnalla |
| Suojauksen skannausvaihe | ✅ Lisäsuojaustyökalut skannaavat kovakoodatut tunnukset, haavoittuvat sidonnaisuudet, CRUD/FLS-rikkomukset ja vaatimustenmukaisuuskäytäntöjen rikkomukset; kriittiset havainnot rikkovat rakenteita |
| UAT-käyttöönoton vaihe | ✅ Muutokset, jotka välittävät kaikki automatisoidut portit, otetaan käyttöön käyttäjien hyväksymisen testausympäristöön liiketoiminnan vahvistusta varten. Käyttöönotto voi olla automatisoitu tai vaatia manuaalisen hyväksymisen muutosten riskin perusteella |
| Tuotannon käyttöönoton vaihe | ✅ UAT-hyväksymisen jälkeen muutokset otetaan käyttöön tuotantoympäristössä, jossa on automatisoitu yhden napsautuksen suoritus, kattava loki ja välitön peruutuskyky |
| Myyntiputken suoritusaika | ✅ Päättymisen myyntiputki suoritetaan alle 15 minuutissa tavallisille muutoksille, jotka mahdollistavat nopean palautteen; pidempiä suurille käyttöönotoille tai laajoille testisarjoille |
| Rakenna artefakteja | ✅ Pipeline säilyttää käyttöönottopaketit, testitulokset, suojaustarkistusraportit ja suorituslokit vaatimustenmukaisuutta ja vianmääritystä varten |
| Myyntiputken työkalut | ✅ Tiimit käyttävät Salesforce DevOps Centeria sovellusalustan natiiviille CI/CD-tiedostoille tai integroituvat ulkoisiin sovellusalustoihin (GitHub-toiminnot, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Virheiden ilmoitukset | ✅ Myyntiputken virheet käynnistävät ilmoituksia sitoutuneille tekijöille ja asiaankuuluville kanaville, joiden diagnostinen konteksti sallii nopean korjauksen |
| Haaran suojaus | ✅ Suojatut pää-/tuotantohaarat, jotka vaativat CI-tarkastusten ja hyväksyttyjen tarkastusten suorittamisen ennen yhdistämistä; suorat sitoumukset estetty |
| Ympäristökampanja | ✅ Muutokset kulkevat määritetyn tarjouskampanjan polun kautta (kehittäminen → integrointi → UAT → tuotanto) ja vahvistus jokaisessa vaiheessa |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Manuaaliset käyttöönotot | ⚡️ Muutokset, jotka on otettu käyttöön manuaalisesti muutosjoukkojen tai Salesforce CLI -komentojen kautta, joilla on epäjohdonmukaisia vaiheita; ihmisten virheet, puuttuvat vaiheet, auditointipolku puuttuu |
| Ei staattista analyysiä | ⚡️ Pipelines ohittaa Salesforce Code Analyzerin tai samankaltaisia työkaluja; tietoturvariskit, suorituskykymallit ja koodin laatuongelmat saavuttavat tuotantoympäristön |
| Riittämätön testaus | ⚡️ Pipeline vahvistaa vähintään 75 % kattavuuden suorittamatta integraatiotestejä tai vahvistamatta tärkeimpiä käyttäjäkulkuja; regressiot läpäisevät |
| Ei tietoturvatarkistusta | ⚡️ Putket eivät koskaan skannaa kovakoodattuja tunnuksia, haavoittuvia sidonnaisuuksia tai CRUD/FLS-rikkomuksia; tuotanto- tai tietoturvatarkastuksissa havaitut tietoturvaongelmat |
| Hitaasti suoritettu myyntiputki | ⚡️ Päättymisen myyntiputki kestää 45–60+ minuuttia, mikä estää usein tehdyt sitoumukset ja hidastaa palautteen silmukoita. Kehittäjät sitoutuvat harvemmin ja keräävät suurempia muutoksia |
| Ohitetut myyntiputken virheet | ⚡️ Tiimit ohittavat tai korvaavat myyntiputken virheitä täyttääkseen määräajat; laatuportaalit muuttuvat teatteriportaaleiksi todellisten ohjainten sijaan |
| Ei testiympäristön pariteettia | ⚡️ CI/CD vahvistaa ympäristössä, jossa on erilainen kokoonpano, rajoitukset tai dataominaisuudet kuin tuotantoympäristössä. Vahvistuksen antaminen ei takaa tuotantoympäristön onnistumista |
| Periytymisen kapasiteetti puuttuu | ⚡️ Pipeline automatisoi käyttöönoton, mutta ei tarjoa automatisoitua periytymistä. Huonosta käyttöönotosta toipuminen vaatii manuaalisia hätätilanteita |
| Ei käyttöönottolokeja | ⚡️ Käyttöönotot suoritettiin ilman kattavaa kirjaamista lokiin; virheiden vianmääritys tai käyttöönottojen auditointi on vaikeaa |
| Kaikki tai ei mitään -testaus | ⚡️ Pipeline suorittaa kaikki testit jokaiselle muutokselle riippumatta muutoksista. 30 minuutin testisarja suoritetaan myös dokumentaation päivityksille |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Ominaisuusmerkinnät | ✅ Korkean riskin muutokset otetaan käyttöön ominaisuuksilla, jotka eivät ole käytössä mukautetun metadatatyypin tai mukautettujen asetusten kokoonpanon jälkeen. Sallii testauksen tuotantoympäristössä ilman käyttäjien altistumista, asteittaisen julkaisun segmenteihin, A/B-testauksen ja välittömän periytymisen kokoonpanon muuttamisen kautta |
| Ominaisuusmerkinnän vaikutusalue | ✅ Ominaisuusmerkinnät, jotka on varattu riskialttiille muutoksille, jotka vaikuttavat kriittisiin liiketoimintaprosesseihin, suorituskykyä koskeviin toimintoihin tai uusiin integraatiokuvioihin. Kaikki ominaisuudet eivät tarvitse merkintöjä |
| Kanarian käyttöönotot | ✅ Liiketoimintaan liittyvät muutokset julkaistaan pienille käyttäjille ensin (5-10 % käyttöoikeusjoukkojen tai käyttäjäattribuuttien suodattamisen kautta); Canary-kohorttia seurattiin intensiivisesti 24–48 tuntia, mittaamalla onnistumissuhteita, suorituskykyä ja virhesuhteita ennen julkaisun laajentamista |
| Käyttöönottoikkunat | ✅ Käyttöönotot, jotka on ajoitettu alhaisen käytön ajanjaksoille, ilmoitetaan Event Monitoring API -käyttölokeilla, jotka näyttävät todelliset liikennekuviot; välttää huippukäytön, kuukauden lopun sulkemisen, vuosineljänneksen lopun sulkemisen, tärkeimmät liiketoimintatapahtumat |
| Käyttöönoton viestintä | ✅ Sidosryhmät saavat käyttöönottovaiheista ennakkoilmoituksen, mukaan lukien odotettu kesto, asiaankuuluvat toiminnot ja peruutuspäätösten aikataulu |
| Periytymistoimenpiteet | ✅ Dokumentoidut ja testatut periytymistoimenpiteet kullekin käyttöönottotyypille. Tiimi voi suorittaa periytymisen alle 30 minuutissa tarvittaessa |
| Palautustestaus | ✅ Periytymistoimenpiteet, jotka on vahvistettu muussa kuin tuotantoympäristössä ennen merkittäviä käyttöönottoja, jotka varmistavat, että palautuskyky on olemassa |
| Käyttöönoton vahvistus | ✅ Käyttöönoton jälkeiset savutestit vahvistavat kriittiset käyttäjäkulut, integraation päätepisteet ja avaintoiminnot välittömästi julkaisun jälkeen |
| Muutoskoordinaatio | ✅ Yhteensopiva käyttöönottostrategia, kun muutokset kattavat useita järjestelmiä tai vaativat synkronoituja julkaisuja Salesforcen ja ulkoisten sovellusalustojen välillä |
| Valvonta käyttöönoton aikana | ✅ Parannettu valvonta, joka on aktiivinen käyttöönottovaiheen ja käyttöönoton jälkeisen havaintojakson aikana (24–48 tuntia) virhesuhteen nousun, suorituskyvyn heikentymisen tai käyttäjäkulun virheiden varalta |
| Integraatioiden sinivihreä kuvio | ✅ Salesforcen ulkoiset palvelut käyttävät sinisen ja vihreän käyttöönottoja, jotka ylläpitävät kahta tuotantoympäristöä, käyttöönotto ei-aktiiviseen ensin, siirto liikenteeseen vahvistuksen jälkeen |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Big Bang -käyttöönotot | ⚡️ Suuri julkaisu, joka sisältää useita samanaikaisesti käyttöönotettuja ominaisuuksia, refaktorointeja ja muutoksia ilman asteittaista julkaisua; virhe vaikuttaa kaikkiin käyttäjiin välittömästi |
| Huipputason käyttöönotot | ⚡️ Julkaisut, jotka on ajoitettu ruuhka-aikojen (keskipäivän, kuukauden lopun, vuosineljänneksen lopun) aikana, kun käyttö on korkeinta ja ongelmien käyttäjävaikutus on maksimoitu |
| Ei periytymissuunnitelmaa | ⚡️ Käyttöönotot tapahtuvat ilman dokumentoituja ja testattuja periytymistoimenpiteitä. Kun ongelmia ilmenee, tiimi yrittää selvittää toipumisen. |
| Ominaisuuden vaihtokytkimet jälkisuunnitteluna | ⚡️ Ominaisuusmerkinnät lisätään uudelleen, kun ongelmia ilmenee, eikä suunniteltu ennakoivasti riskialttiille muutoksille. Rajoittaa peruutusvaihtoehdot täydelliseen käyttöönoton kumoamiseen |
| Ei käyttöönoton vahvistusta | ⚡️ Muutokset otettiin käyttöön tuotantoympäristössä ilman käyttöönoton jälkeisiä savutestejä; tiimi olettaa, että käyttöönotto onnistui ja jatkaa; käyttäjien tunnin kuluttua havaitsemat ongelmat |
| Todentamattomat periytymistoimenpiteet | ⚡️ Periytymismenetelmät on dokumentoitu, mutta niitä ei ole koskaan testattu muussa kuin tuotantoympäristössä. Todellisen vahinkotapahtuman aikana toimenpide epäonnistuu tai osoittautuu riittämättömäksi |
| Samanaikaiset usean järjestelmän muutokset | ⚡️ koordinoidut muutokset Salesforcessa ja ulkoisissa järjestelmissä, jotka on otettu käyttöön ilman synkronointia tai yhteensopivuustestausta; luo integrointivirheitä |
| Ei valvonnan parannusta | ⚡️ Käyttöönotot suoritetaan ilman parannettua valvontaa käyttöönottoikkunan aikana. Ongelmat havaitaan käyttäjien valitusten sijaan ennakoivien hälytysten perusteella |
| Weekend-käyttöönotot | ⚡️ Suuret julkaisut otetaan käyttöön perjantai-iltaisin tai viikonloppuisin, kun puheluiden kattavuus on vähentynyt ja toimittajien tukien saatavuus on rajoitettu |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Yksikkötestien kattavuus | ✅ Selkeä testien kattavuus liiketoimintasääntöjen, reunojen tapausten, virheiden polkujen ja hallintarajoitusten lähestymistavan vahvistamiseksi; ylittää merkittävästi 75 %:n vähimmäisvaatimuksen |
| Yksikön testin laatu | ✅ Testit vahvistavat liiketoimintalogiikan, eivät sovellusalustan toimintoja. Hyvin kirjoitetut yksikkötestit ovat nopeita (millisekunteina), eristettyjä (ei jaettua tilaa) ja keskittyneitä (jokainen testi vahvistaa yhden toimintatavan) |
| Datastrategian testaaminen | ✅ Testit käyttävät @TestSetup-metodeja yleisimmille testitiedoille; vältä SOQL-kyselyitä testeissä, kun se on mahdollista; käytä Test.loadData()-metodia staattisten resurssien lataamiseen |
| Ulkoisten sidonnaisuuksien piilottaminen | ✅ Yksikkötestit esittävät ulkoisia kutsuja käyttämällä testipisteitä ja riippuvuuksien injektiota, mikä mahdollistaa nopean suorituksen ilman todellisia HTTP-pyyntöjä |
| Integrointitestit | ✅ Vahvista käynnistimen, kulkujen, sovellusalustan tapahtumien, erätöiden ja ulkoisten callout-kutsujen väliset vuorovaikutukset, jotka suoritetaan sandboxeissa edustavalla testidatalla |
| Integrointitestien luotettavuus | ✅ Integrointitestit ovat toistettavissa ja deterministisiä; satunnaiset virheet korjataan synkronointimekanismeilla, kuten sovellusalustan tapahtumien toistotunnuksilla ja erätöiden kyselyillä |
| Lopulliset testit | ✅ Automatisoitu selaintestaus (Selenium, Playwright, Provar) vahvistaa kokonaiset käyttäjien matkat liiketoimintakriittisille kuluille, jotka käyttävät järjestelmää käyttöliittymän kautta samalla tavalla kuin käyttäjät vuorovaikuttavat |
| E2E-testin keskitys | ✅ E2E-testit keskittyvät arvokkaimpiin käyttäjäpolkuihin, koska suoritus hidastuu (minuutteja per testi) ja käyttöliittymän muutoksista aiheutuu suurempaa ylläpitotyötä |
| Lataustestaus | ✅ Suorituskyky vahvistetaan todellisten samanaikaisten käyttäjien latausten ja datamäärien perusteella käyttämällä Salesforce Load Testing -palveluita tai kolmansien osapuolten työkaluja; paljastaa hallintarajoitusten ongelmat, lukitsemisen kiistan ja suorituskyvyn heikentymisen |
| Lataustestien yleisyys | ✅ Lataustestit suoritetaan ennen suuria julkaisuja ja säännöllisesti (neljännesvuosittain) suorituskyvyn vahvistamiseksi 3–5 kertaa tämänhetkisellä tuotantomäärällä |
| Testaa pyramidi | ✅ Tasapainoinen testien jakauma: useita yksikkötestejä (satoja, minuutteja), vähemmän integrointitestejä (tuhoja, minuutteja), vähemmän E2E-testejä (alle 20 minuuttia); nopea palaute pohjassa, kattava vahvistus ylälaidassa |
| Testisolaatio | ✅ Testit eivät riipu toisistaan; ne voidaan suorittaa missä järjestyksessä tahansa; jokainen testi jättää järjestelmän puhtaaksi tai käyttää @TestSetup-objektia yhdenmukaiseksi aloituspisteeksi |
| Negatiiviset testitapaukset | ✅ Testit vahvistavat virheiden käsittelyn, vahvistussääntöjen noudattamisen, käyttöoikeuksien noudattamisen ja heikentymisen haitallisissa olosuhteissa |
| Hallintorajoituksen testaaminen | ✅ Testit vahvistavat tarkalleen hallintarajoituksia lähestyvän toimintatavan, mukaan lukien SOQL-kyselyiden rajoitukset, DML-rajoitukset, CPU-aika, pinon koko |
| Jatkuva testien suoritus | ✅ Testit suoritetaan automaattisesti jokaiselle sitoutumiselle CI/CD-putken kautta. Epäonnistuneet testit estävät käyttöönoton korkeammissa ympäristöissä |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Kattavuuden testaaminen | ⚡️ Testit, jotka on kirjoitettu vain 75 %:n vähimmäiskattavuuden saavuttamiseksi ilman liiketoimintasääntöjen tai reunojen vahvistusta; testit, jotka eivät vahvista mitään tai testaavat tavallisia koodipolkuja |
| Sovellusalustan ominaisuuksien testaaminen | ⚡️ Testit vahvistavat, että Salesforce tallentaa tietueita tai SOQL-kyselyitä työnsä liiketoimintalogiikan vahvistamisen sijaan; heikentää sovellusalustan takuita |
| Ei peukalointistrategiaa | ⚡️ Yksikkötestit tekevät todellisia callout-kutsuja ulkoisille järjestelmille; testit ovat hitaita, hauraita ulkoisten järjestelmien saatavuudelle ja kuluttavat API-rajoituksia |
| Satunnaiset testivirheet | ⚡️ Testit läpäisevät tai epäonnistuvat ennustetusti suorituksen ajoituksen, datan tilan tai testin suoritusjärjestyksen perusteella. Tiimit oppivat ohittamaan virheet ja suorittamaan ne uudelleen, kunnes testit läpäisevät. |
| Ei integroinnin testausta | ⚡️ Vain yksikkötestejä on olemassa. Tiimi ei vahvista koskaan, että käynnistimet, kulut, sovellusalustan tapahtumat ja erätyöt toimivat oikein yhdessä |
| Vain manuaalinen E2E-testaus | ⚡️ Kriittiset käyttäjäkulut, jotka vahvistetaan manuaalisesti ennen jokaista julkaisua; ei automatisoituja E2E-testejä; regression havaitseminen tuotantoympäristössä, kun manuaaliset testit ohittavat skenaariot |
| Ei lataustestausta | ⚡️ Suorituskykyä ei vahvistettu koskaan realistisissa samanaikaisissa latauksissa; hallitsevien rajoitusten ongelmat, lukituksen ristiriita tai suorituskyvyn heikkeneminen havaittiin tuotantoympäristössä |
| Datan sidonnaisuuksien testaaminen | ⚡️ Testit riippuvat organisaatiossa olevista tietyistä tietueista tai oletuksena tietystä käyttäjäkokoonpanosta; tauko, kun sandbox päivitetään tai kokoonpano muuttuu |
| Ei negatiivisia testitapauksia | ⚡️ Testit vahvistavat vain tyytyväisten polkujen skenaariot, eivät koskaan testaa virheiden käsittelyä, vahvistuksen käyttöönottoa tai käyttöoikeustarkistuksia, virhetiloja ei löydy |
| Ohitetut testit | ⚡️ Epäonnistuneet testit, jotka on kommentoitu @isTest-testauksesta pois ja ohitettu, eikä korjattu; testisarja heikkenee ajan myötä, kun muita testejä ohitetaan |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Tarkasta kattavuus | ✅ Kaikki tuotantoon liittyvät muutokset kulkevat koodin tarkastuksen kautta noutopyynnöillä, jotka vaativat hyväksynnän ennen yhdistämistä, mukaan lukien Apex, Aura, LWC, kulut, vahvistussäännöt, käyttöoikeusjoukot, jakosäännöt |
| Tarkastusehtojen tarkistuslista | ✅ Selkeä tarkistuslista, joka kattaa tietoturvan (CRUD/FLS-vaatimusten noudattaminen, input-vahvistus), suorituskyvyn (bulkkaaminen, SOQL-optimointi), hallintarajoitusten vaatimustenmukaisuuden (käsittelykuvioita, toistuvuuden estäminen), ylläpitokelpoisuuden (nimittäminen, dokumentaatio, monimutkaisuus), testien kattavuuden (merkitykselliset testit, reunojen tapaukset), arkkitehtonisen johdonmukaisuuden (suunnittelukuvioita, huolenaiheiden erottaminen) |
| Kokorajoitusten tarkastaminen | ✅ Noutopyynnöt, jotka säilytetään 400 riviin sisältyvissä merkityksellisissä muutoksissa, mahdollistavat perusteellisen tarkastuksen; suuret ominaisuudet pilkotaan pieniksi asteittaisiksi muutoksiksi, jotka voidaan tarkastaa yksittäin ja ottaa käyttöön itsenäisesti |
| Tarkastuksen ajoitus | ✅ Yhden arkipäivän sisällä suoritetut tarkastukset, jotka ylläpitävät kehitysnopeutta ja tarjoavat nopeaa palautetta; viivästyneet tarkastukset aiheuttavat asiayhteyden vaihtumisen. |
| Automatisoidut tarkastusta edeltävät tarkastukset | ✅ Staattiset analyysit, yksikkötestit ja tietoturvatarkistus suoritetaan automaattisesti ennen kuin henkilökohtaista tarkastusta pyydetään. Automatisoidut tarkastukset havaitsevat mekaaniset ongelmat, joten tarkastajat keskittyvät suunnitteluun ja liiketoimintalogiikkaan |
| Jaettu tarkastusvastuu | ✅ Koodin tarkastuksen vastuu jaetaan tiimille, mikä estää pullonkaulakohdat ja jakaa Knowledgea; alitason kehittäjät tarkastavat vanhempia koodeja ja selittävät omia koodejaan tarkastusten aikana |
| Tarkasta kommenttien laatu | ✅ Tarkastajat antavat konkreettista ja interaktiivista palautetta perustelulla. Erota pakolliset muutokset (esteiden estäminen) ja ehdotukset (hyväksyttävät parannukset) |
| Tarkasta dokumentaatio | ✅ Noutopyyntöjen kuvaukset selittävät, mitä muuttui, miksi se muuttui, mitä testejä tehtiin ja mitä erityisiä käyttöönotossa huomioitavia asioita tai peruutusmenetelmiä |
| Deklaratiivisen kokoonpanon tarkastus | ✅ Kulut, vahvistussäännöt ja käyttöoikeuksien muutokset tarkastetaan samalla tarkkuudella kuin koodi; kokoonpano on arkkitehtoninen ja ansaitsee tarkastelua |
| Kommenttien seuranta | ✅ Kaikki ennen yhdistämistä käsitellyt tarkastuksen huomautukset; vastatut kysymykset, toteutuneet muutokset tai syy, miksi ehdotusta ei hyväksytty |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Ei koodin tarkastusta | ⚡️ Muutokset, jotka on sitoutettu suoraan tuotanto-osastoon ilman vertaisarviointia; poistaa ensisijaisen virheiden havaitsemisen mekanismin |
| Kumi leimaaminen | ⚡️ Tarkastajat hyväksyvät noutopyyntöjä sekunneissa tarkastamatta muutoksia. Tarkastuksesta tulee valintaruudun vaatimustenmukaisuus laatuportaalin sijaan |
| Yksittäisen tarkastajan pullonkaula | ⚡️ Vain yksi vanhempi kehittäjä, joka on valtuutettu tarkastamaan koodia; luo pullonkaulan ja yksittäisen virhepisteen; Knowledge keskitetään eikä jaeta |
| Joukkopoistopyynnöt | ⚡️ Noutopyynnöt, jotka sisältävät tuhansia rivejä useita ominaisuuksia kattavia muutoksia, joita ei voida tarkastaa huolellisesti, mikä johtaa pinnalliseen tarkastukseen |
| Viivästyneet tarkastukset | ⚡️ Noutopyynnöt pysyvät tarkistamatta päivinä tai viikkoina; kehittäjät menettävät asiayhteyden ja siirtyvät muihin töihin; tarkastelukommentit saapuvat, kun kehittäjä on vaihtanut mielenterveyden asiayhteyteen |
| Ei tarkastusehtoja | ⚡️ Tiimillä ei ole selkeitä ehtoja tarkastajien tarkastettaville kohteille; tarkastuksen laatu vaihtelee tarkastajan mukaan. Jotkin tarkastajat keskittyvät tyyliin, toiset logiikkaan, eikä mikään kattava |
| Tarkastaminen ilman testausta | ⚡️ Tarkastajat hyväksyvät muutokset vain koodin tarkastuksen perusteella vetämättä haaraa ja testaamatta paikallisesti tai vahvistamatta automatisoitujen testien läpäisemistä |
| Ohitetut automatisoidut tarkastukset | ⚡️ Tarkastajat hyväksyvät noutopyyntöjä, vaikka staattiset analyysit, tietoturvatarkistukset tai yksikkötestit epäonnistuisivat; ei täytä automatisoitujen laatuportaalien käyttötarkoitusta |
| Vihamielinen arvostelukulttuuri | ⚡️ Arvosteluista tulee henkilökohtaista kritiikkiä tai kilpailukykyä yhteistyön laadun parantamisen sijaan; estää oppimista ja psykologista turvallisuutta |
| Ei deklaratiivista tarkastusta | ⚡️ Kulut, vahvistussäännöt, käyttöoikeusjoukot ja jakosäännöt otetaan käyttöön ilman tarkistusta, kun Apex tarkastetaan; luo laadun aukon deklaratiivisessa kokoonpanossa |