Resilient – Hantering av programmets livscykel
Lär dig mer om Välarkitektade anpassningsbara → Resilienta → Hantering av programlivscykel → Miljöstrategi
| Var ska man leta? Produktområde | Plats | Hur ser bra ut? Pattern |
|---|---|
| Plattform | Organisation | ✅ Metadata i en given miljö är oberoende av dina releaseartefakter |
| Plattform | Organisation | ✅ Miljöer motsvarar inte direkt en releasesökväg |
| Plattform | Organisation | ✅ Releasevägar för en ändring beror på typen av ändring (hög risk, medel risk, låg risk) |
| Plattform | Organisation | ✅ Överfulla miljöer finns inte |
| Plattform | Organisation | ✅ Riskabla konfigurationsändringar görs aldrig direkt i produktion |
| Plattform | Organisation | ✅ Inga releaser inträffar under rusningstid |
| Plattform | Organisation | ✅ En källdriven utvecklings- och releasemodell används |
| Plattform | Sandboxar | ✅ Källspårning är aktiverad för Developer och Developer Pro sandboxar |
Lär dig mer om Välarkitekturerade anpassningsbara → Resilienta → Programlivscykelhantering → Utgivningshantering
| Var ska man leta? Produktområde | Plats | Hur ser bra ut? Pattern |
|---|---|
| Plattform | Designstandarder | ✅ Releasenamn är tydliga |
| Plattform | Designstandarder | ✅ Team kan hitta och följa tydliga riktlinjer för att tagga artefakter, utvecklingsobjekt och annat arbete med rätt releasenamn |
| Plattform | Dokumentation | ✅ Releasenamn är sökbara och upptäckbara |
| Plattform | Dokumentation | ✅ Det är möjligt att samla en tydlig vy av ett releasemanifest efter releasenamn |
| Plattform | Nyckeltal | ✅ Kvalitetströsklar för generativa AI-appar definieras för olika utvecklingsfaser |
| Plattform | Produktion | ✅ Metadata visar användning av stabila releasemekanismer Distributioner via Metadata API använder source |
| Plattform | Produktion | ✅ Metadata visar användning av stabila releasemekanismer Metadata är organiserad i olåsta paket |
| Plattform | Produktion | ✅ Utplaceringsloggar visar inga misslyckade utplaceringar inom den tillgängliga historiken |
| Plattform | Produktion | ✅ Distributionshistorik visar tydliga releasekadenser och ganska enhetliga distributionskluster inom releasefönster |
| Plattform | Produktion | ✅ DevOps Center är aktivt och installerat |
| Plattform | Produktion | ✅ Metadata visar användning av stabila releasemekanismer Ändringsanvisningar används inte för att släppa ändringar |
| Plattform | Vägkarta | ✅ funktioner är tydligt knutna till en specifik, namngiven utgåva |
| Plattform | Vägkarta | ✅ Releasenamn är tydliga |
| Plattform | Vägkarta | ✅ Releasenamn är sökbara och upptäckbara |
Lär dig mer om Välarkitekturerad anpassningsbar → Resilient → Hantering av programlivscykel → Teststrategi
| Var ska man leta? Produktområde | Plats | Hur ser bra ut? Pattern |
|---|---|
| Data 360 | Apex | ✅ Apex testklasser inkluderar täckning för sökfrågor som körs mot Data Cloud-objekt Testklasser utökar klassen System.SoqlStubProvider och åsidosätter metoden handleSoqlQuery(). DMO-instanser skapas antingen med Test.createStubQueryRow() eller Test.createStubQueryRows(). |
| Platform | Apex | ✅ Data fabriksmönster används för enhetstester |
| Platform | Apex | ✅ Mock / stubbar används för att simulera API-svar |
| Plattform | Företag | ✅ Du inkluderar skaltest som en del av din QA-process när du har appar i B2C-skala, stora volymer användare eller stora volymer data |
| Plattform | Företag | ✅ Dina skala tester har väldefinierade kriterier |
| Plattform | Företag | ✅ Du utför skala tester i en Fullständig sandbox |
| Plattform | Företag | ✅ Dina skala tester är fokuserade högprioriterade aspekter av systemet |
| Plattform | Företag | ✅ Simulatorer används för att replikera produktionsliknande villkor för skalbarhet och prestandatest |
| Plattform | Företag | ✅ Tester är automatiserade för att köras när ändringar kommer till källkontroll |
| Plattform | Företag | ✅ Uthållighet, stress, prestanda och skala tester körs i flera intervaller i programutvecklingscykeln och övervägs pågående uppgifter |
| Plattform | Företag | ✅ Snabb teknik inkluderar en kvalitetsgranskning av en människa |
| Plattform | Företag | ✅ Användbarhetstester använder en mängd olika enheter och hjälpmedelsteknik |
| Plattform | Organisation | ✅ Alla testdata rensas från känsliga och identifierande data |
| Plattform | Testplaner | ✅ Miljöer klassificeras efter vilken typ av tester de kan stödja |
| Plattform | Testplaner | ✅ Lämpliga testregimer specificeras enligt risk, användningsfall eller komplexitet |
Lär dig mer om Välarkitektade anpassningsbara → Resilienta → Hantering av programlivscykel → Miljöstrategi
| Var ska man leta? Produktområde | Plats | Vad ska man undvika? Anti-Pattern |
|---|---|
| Plattform | Organisation | ⚠️ Miljöer direkt motsvarar en releasesökväg |
| Plattform | Organisation | ⚠️ Releasevägen för varje ändring är densamma |
| Plattform | Organisation | ⚠️ Överfulla miljöer finns |
| Plattform | Organisation | ⚠️ Riskabla konfigurationsändringar görs direkt i produktion |
| Plattform | Organisation | ️ En organisationsbaserad utvecklings- och releasemodell används |
| Plattform | Organisation | ⚠️ Utgåvor inträffar under rusningstid |
| Plattform | Organisation | ⚠️ Metadata i en given miljö är din releaseartefakt |
| Plattform | Sandboxar | ⚠️ Källspårning är inte aktiverat för Developer och Developer Pro sandboxar |
Lär dig mer om Välarkitekturerade anpassningsbara → Resilienta → Programlivscykelhantering → Utgivningshantering
| Var ska man leta? Produktområde | Plats | Vad ska man undvika? Anti-Pattern |
|---|---|
| Plattform | Designstandarder | ⚠️ Releasenamn saknas |
| Plattform | Designstandarder | ⚠️ Team refererar till artefakter, utvecklingsobjekt och annat arbete på olika sätt |
| Plattform | Dokumentation | ⚠️ Releasenamn är ad hoc eller finns inte |
| Plattform | Dokumentation | ⚠️ Det går inte att samla en tydlig vy av ett releasemanifest med ett releasenamn |
| Plattform | Nyckeltal | ⚠️ Kvalitetströsklar för generativa AI-appar har inte definierats, eller har inte definierats i olika utvecklingsfaser |
| Plattform | Produktion | ⚠️ Metadata indikerar användning av organisationsbaserade releasemekanismer Distributioner via Metadata API använder package.xml |
| Plattform | Produktion | ⚠️ Metadata indikerar användning av organisationsbaserade releasemekanismer Aktiv användning av ändringsanvisningar |
| Plattform | Produktion | ⚠️ Distributionsloggar visar upprepade instanser av misslyckade distributioner inom den tillgängliga historiken |
| Plattform | Produktion | ⚠️ Utplaceringar har ingen märkbar kadens eller visar ojämna kluster av utplaceringar (tecken på snabbkorrigeringar och ad hoc-återföringar) |
| Plattform | Produktion | ⚠️ DevOps Center är inte aktiverat och installerat |
| Plattform | Vägkarta | ⚠️ Funktioner är inte tydligt knutna till en specifik utgåva |
| Plattform | Vägkarta | ⚠️ Releasenamn saknas |
| Plattform | Vägkarta | ⚠️ Releasenamn är ad hoc eller finns inte |
Lär dig mer om Välarkitekturerad anpassningsbar → Resilient → Hantering av programlivscykel → Teststrategi
| Var ska man leta? Produktområde | Plats | Vad ska man undvika? Anti-Pattern |
|---|---|
| Data 360 | Apex | ⚠️ Testtäckning finns inte för SOQL-frågor som körs mot Data Cloud-objekt SOQL-frågor mot en DMO täcks inte av Apex testmetoder |
| Platform | Apex | ⚠️ Dina enhetstester är beroende av organisationsdata |
| Platform | Apex | ⚠️ Mocka/stubbar används inte |
| Plattform | Företag | ⚠️ Dina skaltester prioriteras inte |
| Plattform | Företag | ⚠️ Du utför inte skaltest som en del av din kvalitetssäkringsprocess och du har appar i B2C-skala, stora volymer användare eller stora volymer data |
| Plattform | Företag | ⚠️ Dina skaltester har inte väldefinierade kriterier |
| Plattform | Företag | ⚠️ Du utför skaltest i en Partial Copy eller Developer Sandbox |
| Plattform | Företag | ⚠️ Användbarhetstester utförs inte, eller utförs på en begränsad uppsättning enheter |
| Plattform | Företag | ⚠️ Produktionsliknande volymer av användarbegäranden, API-trafik och variationer i nätverkshastighet testas inte. |
| Plattform | Företag | ⚠️ Testautomatisering finns inte |
| Plattform | Företag | ⚠️ Snabb teknik saknar en kvalitetsgranskning av en människa |
| Plattform | Företag | ⚠️ Uthållighet, stress, prestanda, skala tester anses vara en fas eller fas i utvecklingen. |
| Plattform | Organisation | ⚠️ Testdata är identiska med produktionsdata |
| Plattform | Testplaner | ⚠️ Det är inte klart vilken miljö som kan stödja vilken typ av tester |
| Plattform | Testplaner | ⚠️ Testregimer kategoriseras inte efter risk, användningsfall eller komplexitet |
| Plattform | Testplaner | ⚠️ Prestandatest för egna LWC är en eftertanke Väntar till slutet av utvecklingscykeln med att testa egna Lightning |
| Plattform | Testplaner | ⚠️ Testa integreringar med mindre än 50 % av förväntad användartrafik Att förlita sig på resultatet av en handfull användare för att anse att ett integreringstest är tillräckligt |