Puedo hablar de esta experiencia dolorosa reciente.
Embalaje: 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 y cuando recuerde agregar nuevos componentes a su paquete, su proyecto se cuelga juntos
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 los tableros 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.
la esperanza de que sea útil -
- Steve carril
Gracias, he investigado esto, y me parece el modo recomendado. ¿Sabes si hay una forma de implementar plantillas de MailMerge usando esta herramienta? Gracias dan – danswain
"Force.com Migration Tool link" está muerto –