what test sfdc deployment salesforce apex-code

deployment - sfdc - test salesforce



Salesforce-Cómo implementar entre entornos(Sandboxes, Live, etc.) (7)

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

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

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

¿Alguien tiene consejos sobre la limitación de los diversos métodos?

¿Puedes incluir todo en un paquete de Interfaz Web?

Estamos buscando implementar los siguientes elementos:

  • Clases de Apex

  • Disparadores de Apex

  • WorkFlows

  • Plantillas de correo electrónico

  • Plantillas de MailMerge: parece que no pueden encontrarlas en Eclipse

  • Campos Personalizados

  • Diseño de página

  • RecordTypes (no parece encontrarlos en el sitio web o Eclipse)

  • ¿Artículos de PickList?

  • SControls

Puedo hablar de esta experiencia dolorosa reciente.

Empaquetado: este es un método muy antiguo que es anterior a la API de metadatos en la que confían Ant y Eclipse. En nuestra experiencia, el único beneficio del empaque es definir su proyecto. Si está usando Eclipse (lo cual hacemos, y lo recomiendo), puede definir su proyecto como basado en un paquete particular. Siempre que recuerde agregar nuevos componentes a su paquete, su proyecto se junta

Una cosa que nos desconcertó por un tiempo, por cierto, son los muchos usos del paquete. Hemos observado lo siguiente:

Paquetes instalados: estos vienen en sabores administrados y no administrados y son realmente, en palabras de una publicación reciente en las juntas de SFDC, para que los ISV desplieguen sus cosas en varias organizaciones desconocidas "por ahí". Los paquetes administrados y no administrados tienen limitaciones que los hacen inadecuados e innecesarios para la implementación desde el desarrollo hasta la producción dentro de una organización o, en cualquier caso, donde se realiza un desarrollo personalizado y no se pretende distribuir el código a una gran base anónima.

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 solo una forma conveniente de mantener unida la definición de un proyecto.

De todos modos, la conclusión a la que me refiero es que nuestro equipo (desarrollo personalizado, no un ISV) no necesita paquetes de ninguna forma.

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

El proceso al que nos estamos inclinando 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 utilizamos Eclipse y, a veces, Ant para la migración. Sin aparente necesidad de paquetes en cualquier lugar.

Por cierto, una cosa más a tener en cuenta: no todos los componentes son migrables. Algunas cosas se deben reconfigurar a mano en el entorno objetivo. Un ejemplo serían los flujos de trabajo basados ​​en el tiempo. Las colas y los grupos también necesitan comportarse, crearse, creo. Del mismo modo, la API de metadatos no puede procesar directamente las eliminaciones de los campos, por lo que si borraste un campo de tu fuente, debes eliminarlo a mano en el destino. También hay otros casos.

Espero que sea útil -

- Steve Lane

A partir de Spring ''09, las plantillas de combinación de correo no son compatibles con los metadatos, pero sí con los tipos de registros. Encontrará tipos de registros 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 para campos estándar no se pueden editar en Spring ''09. Estén atentos para recibir noticias sobre los anuncios de las funciones de verano de 2009.

Actualización: las listas de selección estándar para objetos estándar ahora están expuestas a metadatos (a partir de API v16): http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm

De lo contrario, la respuesta de Steve Lane es bastante precisa. La ventaja de usar paquetes no administrados (lo que Steve llama paquetes no instalados) es que cuando agrega metadatos a un paquete, los metadatos de los que depende se agregarán automáticamente. Por lo tanto, es más fácil obtener un conjunto completo de metadatos que contienen todas sus dependencias. Si mueve repetidamente los metadatos de una organización (recinto) a otra (producción), el enfoque de Steve es probablemente el mejor camino a seguir y, sin duda, el más común en la actualidad. Con frecuencia utilizo paquetes de "desarrolladores" no administrados para mover algo que he desarrollado en una organización a otra organización no relacionada. Para mi propósito, me gusta tener el paquete definido en la organización en lugar de un proyecto / SVN de Eclipse. Pero eso probablemente no tiene sentido si está haciendo un desarrollo de equipo en muchos orígenes de dev / sandbox y ya está usando SVN.

Jesper

De los documentos:

Un paquete debe administrarse para que se publique públicamente en AppExchange y para que sea compatible con las actualizaciones . Una organización puede crear un único 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, lo que permite que el paquete administrado se actualice más adelante. Los paquetes no administrados no incluyen componentes bloqueados y no se pueden actualizar. Además, los paquetes administrados ofuscan ciertos componentes (como Apex) en las organizaciones suscriptoras, a fin de proteger la propiedad intelectual del desarrollador.

La ventaja del paquete administrado sería que le permite a la versión y distribuir fácilmente cosas en múltiples organizaciones de SFDC.

Otra opción es usar Cambiar conjuntos si desea mover metadatos de un entorno limitado a producción.

Actualmente existen algunas limitaciones sobre cómo se pueden usar los conjuntos de cambios:

Enviar un conjunto de cambios entre dos organizaciones requiere una conexión de despliegue. Actualmente, los conjuntos de cambios solo se pueden enviar entre organizaciones que están afiliadas a una organización de producción, por ejemplo, una organización de producción y un sandbox, o dos sandboxes creados a partir de la misma organización.

En cualquier implementación de producción de Salesforce, la API de metadatos es una de las mejores opciones para hacerlo. Hay herramientas que simplifican el trabajo. Mira esta publicación: https://www.deploypkg.com/deploy-to-production/

Todavía estoy luchando con esto yo mismo. Ni el IDE de la herramienta de migración ha resuelto los principales problemas a los que me enfrento, que son los siguientes:

  1. Los paquetes instalados no se pueden implementar en una organización de desarrollador . Debe instalarlos uno por uno manualmente en la Org Dev.

    Si no se puede instalar un paquete en la organización (por ejemplo, porque requiere contraseña, como Marketo Sales Insight , o porque ha quedado obsoleto, como Salesforce para Google Adwords ) y nuestra aplicación tiene dependencias (como referencias a campos en objetos que pertenecen al paquete) entonces no podremos implementar la aplicación.

    Solución alternativa : si un paquete no se puede instalar manualmente en una organización DEv, cada desarrollador necesitará su propio desarrollador Sandbox. Se pueden solicitar sandboxes de desarrollador adicionales desde Salesforce. (Aunque el cliente tiene que estar dispuesto a pagar por ellos ...)

  2. Cuando la zona de pruebas se actualiza desde la producción y actualizamos nuestro proyecto local (que está conectado a SVN) desde el servidor, todos los archivos / códigos adicionales que estaban en el viejo Sandbox pero no están en producción se moverán al nuevo Sandbox.

    Solución alternativa : todos los cambios realizados en la producción se deben replicar en Sandbox y las organizaciones de desarrollador. (Tipo de dolor, pero está bien ...)