Salesforce: cómo implementar entre entornos (sandboxes, live, etc.)

https://stackoverflow.com/questions/577346

05-09-2019
|

Pregunta

Estamos estudiando la posibilidad de establecer un proceso de implementación adecuado.

Por lo que he leído, parece haber 4 métodos para hacer esto.

Copiar y pegar: no queremos hacer esto
Uso del mecanismo "Paquete" integrado en la interfaz web de Salesforce
Opción "Implementar en el servidor" de Eclipse Force IDE
Ant Script (aún no he probado este)

¿Alguien tiene algún consejo sobre la limitación de los distintos métodos?

¿Puedes incluir todo en un paquete de Interfaz Web?

Estamos buscando implementar los siguientes elementos:

Clases Apex
Activadores de ápice
Flujos de trabajo
Plantillas de correo electrónico
Plantillas de MailMerge: parece que no puedo encontrarlas en Eclipse
Campos Personalizados
Diseño de página
RecordTypes (parece que no puedo encontrarlos en el sitio web o en Eclipse)
¿Elementos de la lista de selección?
Controles

Solución

recomiendo la migración Force.com herramienta .

Para referencia:

La herramienta de migración le permite utilizar ant para mover su metadatos entre salesforce.com organzations.

Otros consejos

Puedo hablar de esto a partir de una experiencia dolorosa reciente.

Embalaje:Este es un método muy antiguo que es anterior a la API de metadatos en la que se basan tanto Ant como Eclipse.Según nuestra experiencia, el único beneficio del packaging está en la definición de su proyecto.Si está utilizando Eclipse (lo cual hacemos y lo recomiendo), puede definir su proyecto como basado en un paquete en particular.Siempre que recuerde agregar nuevos componentes a su paquete, su proyecto se mantendrá unido

Por cierto, una cosa que nos desconcertó por un tiempo son los múltiples usos del paquete.Hemos observado lo siguiente:

Paquetes instalados:Estos vienen en versiones administradas y no administradas y, en realidad, en palabras de una publicación reciente en los foros de SFDC, los ISV implementan sus cosas en varias organizaciones desconocidas "ahí fuera".Tanto los paquetes administrados como los no administrados tienen limitaciones que los hacen inadecuados e innecesarios para su implementación desde el desarrollo hasta la producción dentro de una organización o, en cualquier caso, cuando realiza un desarrollo personalizado y no tiene la intención de distribuir código a una base anónima grande.

Paquetes no instalados:esto es lo que ve cuando hace clic en "Paquetes" en la interfaz de usuario web.Estos, que a veces llamamos "paquetes de desarrollo", parecen ser simplemente una forma conveniente de mantener unida la definición de un proyecto.

De todos modos, la conclusión a la que llego es que nuestro equipo (de desarrollo personalizado, no un ISV) no necesita paquetes de ningún tipo.

Las otras formas de implementación, tanto Eclipse como Ant, se basan en la API de metadatos.En teoría son capaces de hacer exactamente las mismas cosas.En realidad parecen ser complementarios.La herramienta de migración Force.com, integrada en el IDE de Force.com para Eclipse, hace que la implementación sea lo más fácil posible (lo cual no es muy) y le brinda una buena visión de lo que pretende implementar.Por otro lado, hemos visto a Ant hacer algunas cosas que el IDE no podía hacer.Entonces probablemente valga la pena aprender ambos.

El proceso hacia el que nos inclinamos es mantener todos nuestros proyectos en SVN y usar la estructura SVN como definición del proyecto (Eclipse trabajará con esto y lo respetará).Y usamos Eclipse y, a veces, Ant para la migración.No hay necesidad aparente de paquetes en ninguna parte.

Por cierto, una cosa más a tener en cuenta: no todos los componentes son migrables.Algunas cosas deben reconfigurarse manualmente en el entorno de destino.Un ejemplo serían los flujos de trabajo basados en el tiempo.Creo que las colas y los grupos también deben crearse a mano.Del mismo modo, la API de metadatos no puede procesar directamente la eliminación de campos, por lo que si eliminó un campo en su origen, deberá eliminarlo manualmente en el destino.También hay otros casos.

Espero que sea útil.

--Steve Lane

A partir de la primavera '09, las plantillas de combinación de correspondencia no se admiten en los metadatos, pero los tipos de registro son. Va a encontrar los tipos de registro como un elemento XML en el archivo para el objeto al que pertenecen. Todo lo demás en su lista es compatible con una pequeña excepción. los valores de lista de selección de campos estándar no se pueden editar en la primavera del '09. Manténgase atento a las noticias en verano '09 anuncios de funciones.

Actualización: picklists Uniformes sobre objetos estándar están ahora estos metadatos expuestos (a partir de V16 API): http://www.salesforce.com/us/developer/ docs / api_meta / contenido / meta_picklist.htm

De lo contrario, la respuesta de Steve Lane es bastante exacto. La ventaja de utilizar los paquetes no administrados (lo que Steve llama paquetes no instalados) es que, al añadir metadatos a un paquete, se agregará automáticamente los metadatos que depende. Por lo que es más fácil de agarrar un completo conjunto de metadatos que contiene todas sus dependencias. Si usted se está moviendo en repetidas ocasiones los metadatos de un org (caja de arena) a otro (de producción), el enfoque de Steve es probablemente el mejor camino a seguir y ciertamente el más común hoy en día. Suelo utilizar paquetes no administrados "Desarrollador" mover algo que he desarrollado en una org org a otro no relacionado. Para mi propósito, me gustaría tener el paquete definido en el organigrama en oposición a un proyecto de Eclipse / SVN. Pero que probablemente no tiene sentido si se está haciendo el desarrollo del equipo a través de muchos orgs dev / caja de arena y ya están utilizando SVN.

Jesper

Otra opción es usar Cambio Establece si desea mover los metadatos de una caja de arena para la producción.

En este momento hay algunas limitaciones en cuanto se pueden utilizar conjuntos de cambios:

El envío de un conjunto de cambios entre dos organizaciones requiere un despliegue conexión. Actualmente, conjuntos de cambios sólo se pueden enviar entre organizaciones que están afiliadas a una organización de producción, para ejemplo, una organización de la producción y una caja de arena, o dos cajas de arena creado a partir de la misma organización.

A partir de los documentos:

Un paquete debe ser gestionado para que sea publicado públicamente en AppExchange, y para que admite actualizaciones . Una organización puede crear un solo paquete administrado que puede ser descargado e instalado por muchas organizaciones diferentes. Se diferencian de los paquetes no administrados en que algunos componentes están bloqueados, permitiendo que el paquete arreglado para ser actualizado más tarde. paquetes no administrados no incluyen componentes bloqueadas y no se pueden actualizar. Además, paquetes gestionados ofuscar ciertos componentes (como Apex) sobre la suscripción organizaciones, a fin de proteger la propiedad intelectual de los desarrolladores.

Ventaja de paquete gestionado sería que le permite fácilmente y distribuir la versión cosas a través de múltiples organizaciones SFDC.

Todavía estoy luchando con esto por mí mismo. Ni el IDE de la herramienta de migración han resuelto los principales problemas que enfrentamos, que son los siguientes:

Los paquetes instalados no puede ser enviado a un desarrollador Org . Tienes que instalarlas manualmente una por una en el Dev Org.

Si un paquete no puede ser instalado en el organigrama (por ejemplo, debido a que requiere una contraseña, como Marketo Sales Insight , o porque no tiene quedado en desuso, como Salesforce for Google AdWords ) y nuestra aplicación tiene dependencias en él (como referencias a campos en los objetos que pertenecen a la paquete), entonces no será capaz de desplegar la aplicación.

Solución : si un paquete no se puede instalar de forma manual en un DEv Org cada desarrollador tendrá su propia caja de arena desarrollador. Los areneros de desarrollo adicionales se puede pedir a Salesforce. (El cliente tiene que estar dispuesto a pagar por ellos, aunque ...)
Cuando la caja de arena se actualiza desde la producción y refrescar nuestra proyecto local (que está conectado al SVN) desde el servidor de todos archivos adicionales / código que estaba en en el antiguo recinto de seguridad, pero no es en la producción va a ser trasladado a la nueva caja de arena.

Solución : todos los cambios realizados en la producción deben ser replicados en el recinto de seguridad y la Org desarrollador. (una especie de dolor, pero está bien ...)

En cualquier implementación de producción de Salesforce, la API de metadatos es una de las mejores opciones para hacerlo. Existen herramientas que simplifican el trabajo. Echa un vistazo a este post: https://www.deploypkg.com/deploy-to-production/

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow