Dynamics CRM 2011: soluzioni gestite o distribuzione delle modifiche da DEV a PRD

Question

Per Dynamics CRM 2011, Microsoft suggerisce di spostare le personalizzazioni delle entità da DEV a PRD inserendo le modifiche come soluzioni gestite (o non gestite). Unmanaged è sbagliato perché non è possibile rimuovere le entità quando è necessario (l'eliminazione della soluzione elimina solo il contenitore, le entità contenute nella soluzione rimangono). Nella maggior parte degli esempi di laboratorio durante la formazione, devi personalizzare il sistema, quindi esportare l'entità personalizzata come soluzione gestita, quindi importarla in produzione. Questo approccio basato sulla soluzione è pulito, semplifica il controllo di ciò che è in PRD, raggruppa le entità correlate insieme, tiene traccia delle dipendenze, ecc., Quindi ho capito.

In alcuni casi, tuttavia, è necessario scaricare l'organizzazione sul server DEV e ripristinare da PRD (per risolvere un problema specifico dei dati o per altri motivi). Lo facciamo disabilitando, quindi eliminando l'organizzazione DEV, quindi chiedendo al team DBA di ripristinare il database CRM dalla produzione, quindi importiamo l'org sul server DEV. Ma se implementiamo questo processo di migrazione delle modifiche basato sulle "soluzioni gestite", non perderemo la capacità di cambiare le nostre entità dopo aver scaricato DEV e ricreato da PRD, dove queste soluzioni sono in modalità di sola lettura? Se abilitiamo le personalizzazioni in queste soluzioni gestite, saremo in grado di aggiungere nuove entità alle soluzioni o rimuovere entità dall'interno delle soluzioni senza eliminare l'intera soluzione? Perché pensavo che le soluzioni gestite fossero trattate come una singola unità di codice, quindi è possibile eliminare tutto o eliminare nessuna. Interessato ad apprendere come gli altri hanno risolto questo problema.

Answer 1

Un modo in cui è stato gestito questo è l'utilizzo di una macchina separata di sviluppo pulito che usiamo per gestire le configurazioni come "master di configurazione". Quella macchina non viene utilizzata per altri lavori di sviluppo o test. Le macchine di sviluppo per plugsin, ecc. Possono essere ricostruite da prod, ma questa macchina continua a essere il master per tutte le soluzioni. Non è una soluzione ideale, ma evita il "gap di funzionalità" di essere in grado di convertire le soluzioni gestite a non gestite (magari attraverso una funzionalità di password)

Answer 2

Vorrei sconsigliare l'utilizzo di soluzioni in questo tipo di dev-to-testing- situazione dei prodotti.

Se non si è sicuri di ciò, provare a rimuovere un'entità nell'ambiente di sviluppo e pubblicare le modifiche all'ambiente di produzione.

Le soluzioni sono inclusive, il che significa che CRM non rimuove i campi e le entità che sono stati eliminati nella soluzione.

L'unico modo per rimuovere un'entità è disinstallare la soluzione, quindi eliminare i dati di produzione in tutte le entità coperte dalla soluzione!

Mentre in teoria le soluzioni sembrano perfette sono utili solo per i fornitori di terze parti.

L'obiettivo di essere in grado di eseguire il rollback disinstallando la propria soluzione è un vero sogno. Considera un aggiornamento del modello di dati che implica la conversione dei dati. Nessuna funzione magica invertirà questo.

È molto più semplice e affidabile ripristinare il backup.