2012-10-02 16 views
5

Para Dynamics CRM 2011, Microsoft sugiere trasladar personalizaciones de entidades de DEV a PRD al empaquetar los cambios como soluciones administradas (o no administradas). No administrado es malo porque no puede eliminar las entidades cuando lo necesite (al eliminar la solución solo se elimina el contenedor, las entidades contenidas en la solución permanecen). En la mayoría de los ejemplos de laboratorio durante el entrenamiento, personaliza el sistema, luego exporta la entidad personalizada como una solución administrada y luego la importa a la producción. Este enfoque basado en soluciones es limpio, hace que sea más fácil controlar lo que hay en PRD, agrupar entidades relacionadas, rastrear dependencias, etc., así lo entiendo.Dynamics CRM 2011: soluciones administradas o implementación de cambios de DEV a PRD

Hay veces, sin embargo, cuando necesita volcar la organización en el servidor DEV y restaurar desde PRD (para tratar un problema específico de datos o por otros motivos). Hacemos eso deshabilitando, luego eliminando la organización DEV, luego solicitamos al equipo de DBA que restaure la base de datos de CRM de la producción, luego importamos la organización de regreso al servidor de DEV. Pero si implementamos este proceso de migración de cambio basado en "soluciones administradas", ¿no perderemos la capacidad de cambiar nuestras entidades después de volcar DEV y recrearlo desde PRD, donde estas soluciones están en modo de solo lectura? Si habilitamos las personalizaciones en estas soluciones administradas, ¿podremos agregar nuevas entidades a las soluciones o eliminar entidades dentro de las soluciones sin eliminar toda la solución? Porque pensé que las soluciones administradas se tratan como una sola unidad de código, por lo que es eliminar todo o eliminar ninguno. Interesado en aprender cómo otros han resuelto este problema.

Respuesta

2

Una forma en que hemos manejado esto es usando una máquina de limpieza limpia separada que usamos para administrar las configuraciones como el "maestro de configuración". Esa máquina no se usa para ningún otro desarrollo o trabajo de prueba. Las máquinas de desarrollo para plugsin, etc. pueden reconstruirse a partir de prod, pero esta máquina sigue siendo la maestra para todas las soluciones. No es una solución ideal, pero evita la "brecha de características" de poder convertir soluciones administradas a no administradas (quizás a través de alguna función de contraseña)

2

Recomendaría no utilizar soluciones en este tipo de dev-to-testing- situación to-prod.

Si no está seguro de esto intente eliminar una entidad en su entorno de desarrollo y publique el cambio en su entorno de producción.

Las soluciones son inclusivas, lo que significa que CRM no elimina los campos y entidades que fueron eliminados en su solución.

La única forma de eliminar una entidad es desinstalar la solución y, por lo tanto, eliminar los datos de producción en todas las entidades cubiertas por la solución.

Si bien en teoría las soluciones parecen perfectas, solo son útiles para terceros proveedores.

El objetivo de ser capaz de deshacer mediante la desinstalación de su solución es una quimera. Considere una actualización del modelo de datos que involucra conversión de datos. Ninguna función mágica revertirá eso.

Es mucho más sencillo y confiable restaurar la copia de seguridad.

Cuestiones relacionadas