¿Mejores prácticas para el desarrollo de aplicaciones administradas de SalesForce?

Question

Estamos desarrollando aplicaciones para AppExchange y estamos tratando de descubrir la mejor manera de hacer gestión de desarrollo y lanzamiento. Hay varios problemas al respecto:

1) Prefijos de paquete. Estamos desarrollando código en modo no administrado y liberado como administrado, por lo que debemos agregar todos los prefijos del paquete en el código. ¿Hay alguna manera de hacer esto dinámicamente en tiempo de ejecución? En este momento estamos usando un script Ant, que nos impide beneficiarnos del complemento IDE de force.com.

2) Archivos de recursos ... Estamos haciendo algunas cosas ajax-ey y como resultado tenemos algunos archivos de recursos diferentes que cargamos, algunos de los cuales son recursos de archivos múltiples (archivos zip). ¿Alguien ha automatizado la construcción de estos recursos usando ANT, y funciona bien?

Nuestro entorno parece muy frágil y funciona para algunos desarrolladores y no para otros; ¿otras personas tuvieron este problema? ¿Cómo lo resolvió?

Answer 1

Odio decirlo, pero parece que te has acostumbrado al mejor enfoque que conozco. El entorno de empaque de Salesforce puede ser una pesadilla total para trabajar. Una vez que su paquete administrado tiene un prefijo, no hay retorno a un paquete simple sin uno a menos que lo haga como lo hizo. Por lo tanto, encontrará el nombre del paquete salpicado en todo su código, que el sistema agregará para usted.

He encontrado que la mejor manera de trabajar con él es mantener una versión "pura" de tu aplicación, que se instalará limpiamente en una organización dev desde Ant. Una vez que tenga el código en Ant, se puede agregar al control de fuente "normal". No parece que se hayan creado demasiadas aplicaciones de gran escala en Salesforce con varios miembros del equipo, porque, por lo que puedo ver, no hay mucho soporte para un flujo de trabajo que incluya control de código fuente. Intentaron agregar algún tipo de administración de versiones a una configuración de organización dev, que ahora está en beta, pero no parecía tan buena en absoluto.

Creo que Ant utilizando la herramienta de migración Salesforce Force.com es el camino a seguir en su mayor parte. Luego, sin embargo, una vez que desee crear un paquete administrado, se quedará atrapado con esa base de código congelada, con ese prefijo, donde tendrá que hacer versiones de empaquetado (desde beta, etc.) desde el sistema de empaquetado. sí mismo. La mejor forma de actualizar el entorno de pruebas (límite de una vez al mes), luego haga que los desarrolladores salgan de ese entorno limitado y se desplieguen en grupos de desarrolladores individuales, que luego pueden fusionarse periódicamente en un "grupo dev org", antes Despliegue nuevamente dentro del Sandbox (usando Force.com IDE o Ant), luego en Production.

Todo el proceso es básicamente un desastre total. Salesforce está tan cerca de tener una plataforma súper poderosa, pero muchas veces se siente como un increíble auto deportivo sin volante.

En cuanto a los recursos estáticos, los que debería poder automatizar de forma relativamente sencilla con Eclipse, para poder implementarlos por separado en un solo paso. La API también debería ser compatible.

He trabajado en algunas bases de código Apex bastante grandes (creo, y espero), y realmente no hay una solución aparentemente elegante, me temo. Te quedarás atrapado con extrañas combinaciones de implementación usando Ant en algunos casos, Eclipse otros, etc.

Viniendo de otros entornos de desarrollo, a menudo es confuso y simplemente extraño. Por ejemplo, es desconcertante que no pueda volcar fácilmente la base de datos en un solo paso mientras realiza un seguimiento de las relaciones entre los objetos y luego "importar" en otra organización en un solo paso. De hecho, tuvimos que escribir una herramienta que facilitara la extracción de todos los datos al atravesar relaciones entre objetos, cargar todos los datos, borrar datos de forma recursiva, etc. desde un archivo xls porque necesitábamos una forma fácil de probar en orgs.

Por cierto, los desarrolladores son básicamente orgs. Creamos docenas de ellos para diferentes propósitos de prueba y para mantener diferentes versiones y configuraciones.

Lo siento, no pude darle una mejor noticia. Puede haber más de un gurú aquí que pueda señalar una forma elegante de administrar el embalaje, ¡y estaré tan interesado en ti como la respuesta! ¡Puede enviarme un correo electrónico a suprasphere --- at --- gmail si quiere compadecerse! :)

Answer 2

Recientemente hemos cambiado al uso de un Administrador de prefijos en lugar de hacer sustituciones de hormigas.

Aquí está nuestro código.

public class PrefixMgr { 
    private static string objPrefix = null; 

    public static string getObjPrefix() { 
     if(objPrefix == null) { 
      try { 
       Database.query('select MyColumn__c from my_prefix__MySmallTable__c'); 
       objPrefix = 'my_prefix__'; 
      } 
      catch(Exception e) { 
       objPrefix = ''; 
      } 
     } 

     return objPrefix; 
    } 

    public static string getAppPrefix() { 
     return 'my_prefix__'; 
    } 

    public static string getObjName(string inp) { 
     return getObjPrefix() + inp; 
    } 
} 

Básicamente esto intenta una consulta (una vez) contra una tabla con el nombre prefijado. Si no existe, entonces estamos en modo no administrado sin prefijos de paquete. Si tiene éxito, entonces establecemos el prefijo apropiadamente. getObjName es una conveniencia porque PrefixMgr.getObjName('MyObject__c') es más fácil de leer (esp en una cadena concat) que PrefixMgr.getObjPrefix() + 'MyObject__c'.

Interesados ​​en pensamientos y comentarios.