Ti trovi qui:
Procedure consigliate per il progetto DevOps Center
Seguire queste procedure consigliate per pianificare il progetto DevOps Center. Project è un'area di lavoro centralizzata che consente di gestire e distribuire una raccolta distinta di voci su cui lavorare correlate.
Versioni (Edition) richieste
| Disponibile nelle versioni: Lightning Experience nelle versioni Professional Edition (accesso API richiesto), Enterprise Edition, Performance Edition, Unlimited Edition e Developer Edition |
| Non disponibile in: Government Cloud Plus. Per ulteriori dettagli, rivolgersi al responsabile account Salesforce. |
| Non disponibile in: Area operativa del'Unione Europea. L'area operativa dell'Unione Europea è un'offerta a pagamento speciale che offre un livello avanzato di impegni per la data residency. DevOps Center è supportato nelle organizzazioni dell'UE che non fanno parte dell'area operativa, in base ai termini e alle condizioni standard del prodotto. |
Determinazione del numero di progetti
Utilizzare un singolo progetto e un singolo repository quando:
- I team lavorano sugli stessi metadati e dati di configurazione o su dati dipendenti.
- Tutte le modifiche vengono distribuite alla stessa organizzazione di produzione.
- È necessaria una visibilità unificata per tutto il lavoro.
- Lo sviluppo coinvolge oggetti e funzioni interconnesse.
Creare progetti separati quando:
- I team lavorano su metadati e dati indipendenti senza dipendenze.
- Le modifiche vengono distribuite a organizzazioni di produzione diverse.
- I progetti seguono pianificazioni di rilascio e governance separate.
- È necessario utilizzare pipeline di hotfix isolate per ignorare le cadenze di rilascio standard.
- I team richiedono l'isolamento operativo o preferiscono limitare la visibilità del lavoro attivo e delle modifiche di un altro team.
Selezione della strategia per il ciclo di vita del progetto
Decidere un ciclo di vita del progetto in base ai processi di gestione dei rilasci e alla cadenza.
Progetti in corso: Utilizzare lo stesso progetto in più sprint e rilasci. Questo è l'approccio consigliato per i team con sviluppo di funzioni in corso e metadati e ambito dati stabili. Questi progetti sono più facili da gestire. Ad esempio, i progetti di lunga durata sono ideali per un team che rilascia ogni due settimane e utilizza una pipeline indipendentemente dallo sprint. È possibile monitorare le prestazioni dei progetti utilizzando le metriche e la cronologia DORA in Cronologia attività.
Progetti per rilascio: Creare un progetto per ogni rilascio principale. Questo approccio funziona meglio per i team con iniziative discrete e limitate nel tempo o rilasci di versioni principali. Ciò richiede più lavoro di impostazione per ogni rilascio. Si consiglia di archiviare i progetti dopo il rilascio.
Progetti Hotfix: Per problemi critici di produzione, utilizzare un progetto di hotfix separato per supportare una soluzione più rapida.
- Creare un progetto e connettersi a una pipeline che contiene almeno un ambiente di sviluppo, una fase di test e un'organizzazione di produzione.
- Dopo aver risolto il problema, spostare tutte le modifiche nella pipeline del progetto standard e mantenere sincronizzati tutti gli ambienti.
- Sincronizzare sempre le modifiche al progetto principale per evitare divergenze tra rami.
Gestione dei progetti inattivi
Non è possibile eliminare un progetto in DevOps Center. Aggiungere un prefisso z_ al progetto inattivo. Ad esempio, z_MyOldProject. In questo modo il progetto viene spostato in fondo all'elenco.
Configurazione del file .forceignore
Il file .forceignore determina quali modifiche DevOps Center esclude durante la conferma e la distribuzione. Configurare il file .forceignore nel branch principale prima di creare la pipeline in modo che si propaghi a tutti i branch della funzione. Per modificare un file .forceignore, applicare le modifiche all'interno del branch della funzione delle voci su cui lavorare. Le modifiche si propagano attraverso la pipeline mentre si promuove la voce su cui lavorare. Vedere Esclusione dei metadati con .forceignore File.
Consigli strategia di progetto DevOps Center
| SCENARIO | Consiglio | Esempio |
|---|---|---|
| Stessa organizzazione di produzione con metadati e dati sovrapposti. | Un progetto, una struttura di repository | Un team piattaforma personalizza gli oggetti interconnessi. Il team sviluppa le funzioni di Sales Cloud, in cui gli sviluppatori personalizzano l'oggetto Opportunità mentre altri lavorano sulle Campagne. Entrambe le funzioni utilizzano oggetti personalizzati condivisi. Utilizzare un progetto perché i metadati si sovrappongono. |
| Stessa organizzazione di produzione con metadati e dati indipendenti. | Una struttura di progetto (preferita) | Tracce di lavoro parallelo in cui un team Apex e un team connettore Marketing Cloud vengono distribuiti in un ambiente condiviso. |
| Organizzazioni di produzione separate geograficamente o operativamente. | Progetti separati | Distribuzioni indipendenti per separare le organizzazioni di produzione europee e statunitensi a causa dei requisiti di residenza dei dati. Le organizzazioni contengono app simili ma vengono distribuite in modo indipendente. Creare due progetti, uno per ogni organizzazione di produzione. |
| Urgente, percorso della pipeline di hotfix richiesto. | Progetto hotfix separato | Correzioni critiche che richiedono un percorso isolato per ignorare il ciclo di rilascio standard. |
