Du er her:
Gode fremgangsmåter for DevOps Center
Følg disse gode fremgangsmåtene for å planlegge DevOps Center. Prosjekt er et sentralisert arbeidsområde for å behandle og distribuere en distinkt samling av relaterte arbeidselementer.
Nødvendige utgaver
| Tilgjengelig i Lightning Experience i Professional (API-tilgang kreves), Enterprise, Performance, Ubegrenset og Developer Edition |
| Ikke tilgjengelig i Government Cloud Plus. Kontakt din Salesforce-kundeansvarlig for å få flere detaljer. |
| Ikke tilgjengelig i EU Operating Zone. EU-operasjonssone er et spesielt betalt tilbud som gir et forbedret nivå av dataoppbevaringsforpliktelse. DevOps Center er støttet i organisasjoner i EU som ikke er en del av EU OZ, i henhold til standard produktvilkår. |
Bestem antall prosjekter
Bruk ett enkelt prosjekt og ett enkelt oppbevaringssted når
- Team arbeider på samme eller avhengige metadata og konfigurasjonsdata.
- Alle endringer distribueres til samme produksjonsorganisasjon.
- Du trenger forent synlighet på tvers av alt arbeid.
- Utvikling involverer sammenkoblede objekter og funksjoner.
Opprett separate prosjekter når
- Team arbeider med uavhengige metadata og data uten avhengigheter.
- Endringer distribueres til forskjellige produksjonsorganisasjoner.
- Prosjekter følger separate utgivelsesplaner og styring.
- Du trenger isolerte hurtigreparasjonsreparasjoner under behandling for å omgå standard utgivelseskadenser.
- Team krever operasjonell isolasjon eller foretrekker å begrense synligheten til det aktive arbeidet og endringene i et annet team.
Velge en livssyklusstrategi for prosjektet
Bestem deg for en prosjektlivssyklus basert på utgivelsesbehandlingsprosessene og kadensen.
Pågående prosjekter: Bruk det samme prosjektet på tvers av flere sprint og utgivelser. Dette er den anbefalte løsningen for team med pågående funksjonsutvikling og stabile metadata og dataomfang. Disse prosjektene er enklere å vedlikeholde. Langlivede prosjekter er for eksempel ideelle for et team som utgir hver andre uke og bruker én pipeline uavhengig av sprint. Du kan spore prosjektytelsen ved å bruke DORA-målinger og -historikk i Aktivitetshistorikk.
Prosjekter per utgivelse: Opprett et prosjekt for hver hovedutgivelse. Denne løsningen fungerer bedre for team med diskrete, tidsbestemte initiativer eller store versjonsutgivelser. Dette krever mer oppsettarbeid for hver utgivelse. Vi anbefaler at du arkiverer prosjektene etter utgivelsen.
Hotfix-prosjekter: Til kritiske produksjonsproblemer bruker du et separat hurtigreparasjonsprosjekt for å støtte raskere avslutning.
- Opprett et prosjekt og koble til en pipeline som inneholder minst et utviklingsmiljø, en testfase og en produksjonsorganisasjon.
- Når du har løst problemet, flytter du alle endringene gjennom standardprosjektet under behandling og holder alle miljøer synkronisert.
- Synkroniser alltid endringer tilbake til hovedprosjektet for å hindre avvik mellom grener.
Behandle inaktive prosjekter
Du kan ikke slette et prosjekt i DevOps Center. Legg til et z_-prefiks i det inaktive prosjektet. For eksempel z_MyOldProject. Dette flytter prosjektet til nederst i listen.
Konfigurere .forceignore-filen
.forceignore-filen bestemmer hvilke endringer DevOps Center ekskluderer under bekreftelse og distribusjon. Konfigurer .forceignore-filen i hovedforgreningen før du bygger pipelinen slik at den overføres til alle funksjonsforgreningene. Hvis du vil endre en .forceignore-fil, bruker du redigeringene i funksjonsforgreningen for arbeidselementer. Redigeringene overføres gjennom pipelinen mens du promoterer arbeidselementet. Se Utelukke metadata med .forceignore-fil.
Anbefalinger av DevOps Center
| SCENARIUM | Anbefaling | Eksempel |
|---|---|---|
| Samme produksjonsorganisasjon med overlappende metadata og data. | Ett prosjekt, én repositoriumsstruktur | Et plattformteam tilpasser sammenkoblede objekter. Teamet ditt utvikler Sales Cloud-funksjoner der utviklere tilpasser Salgsmulighet-objektet mens andre arbeider med kampanjer. Begge funksjonene bruker delte tilpassede objekter. Bruk ett prosjekt fordi metadataene overlapper hverandre. |
| Samme produksjonsorganisasjon med uavhengige metadata og data. | Én prosjektstruktur (foretrukket) | Parallelt arbeid sporer hvor et Apex og et Marketing Cloud-koblingsteam distribueres til et delt miljø. |
| Geografisk eller operativt atskilt produksjonsorganisasjoner. | Separate prosjekter | Uavhengige distribusjoner for å skille produksjonsorganisasjoner i Europa og USA på grunn av krav til dataoppbevaring. Organisasjonene inneholder apper som ligner hverandre, men distribueres uavhengig. Opprett to prosjekter, ett for hver produksjonsorganisasjon. |
| Path for hurtigreparasjon under arbeid kreves. | Adskilt hotfix-prosjekt | Viktige rettelser som krever en isolert bane for å omgå standardutgivelsessyklusen. |
