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

package development-environment

Question

Estamos desarrollando aplicaciones para AppExchange y estamos tratando de descubrir la mejor manera de hacer el desarrollo y la administración de versiones. Hay varios problemas alrededor de esto:

1) Prefijos del paquete. Estamos desarrollando código en modo no administrado y liberando como administrado, por lo que debemos agregar todos los prefijos de paquetes en el código. ¿Hay una 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 de 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 utilizando ANT, y eso funciona bien?

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

Answer 1

Odio decirlo, pero parece que te has fijado en el mejor enfoque que conozco. El entorno de empaquetamiento de Salesforce puede ser una pesadilla total para trabajar. Una vez que su paquete administrado tiene un prefijo, realmente no hay vuelta atrás a un paquete simple sin uno a menos que lo guarde como lo ha hecho. Por lo tanto, encontrará el nombre del paquete en 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 su 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 construido demasiadas aplicaciones a gran escala en Salesforce con varios miembros del equipo, porque, por lo que puedo decir, 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 de desarrollo, que ahora está en versión beta, pero no parecía tan bueno en absoluto.

Creo que Ant utilizando la herramienta de migración de Salesforce Force.com es el camino a seguir en su mayor parte. Entonces, sin embargo, una vez que quiera crear un paquete administrado, quedará atrapado con ese código base congelado, con ese prefijo, donde tendrá que hacer lanzamientos de paquetes (desde la versión beta, etc.) desde dentro del sistema de paquetes. sí mismo. La mejor manera de hacerlo es actualizarse a la zona de pruebas (¡¡límite de una vez al mes!), Luego hacer que los desarrolladores se retiren de esa caja de arena y se implementen en organizaciones de desarrolladores individuales, que luego se pueden combinar periódicamente en una "organización de desarrollo de grupos", antes de desplegando nuevamente en el Sandbox (usando Force.com IDE o Ant), luego en Producción.

Todo el proceso es básicamente un completo desastre. 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, debería poder automatizar de forma relativamente sencilla utilizando Eclipse, de modo que pueda implementarlos por separado en un solo paso. La API también debería soportarlo.

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

Viniendo de otros entornos de desarrollo, a menudo es desconcertante 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 puede "importarlo" a otra organización en un solo paso. De hecho, tuvimos que escribir una herramienta que facilitaría la extracción de todos los datos al atravesar relaciones de objetos, cargar todos los datos, eliminar datos de forma recursiva, etc. de un archivo xls porque necesitábamos una forma fácil de probar en las organizaciones.

Por cierto, las organizaciones de desarrollo son básicamente organizaciones de desecho. Creamos docenas de ellos para diferentes propósitos de prueba y para mantener diferentes versiones y configuraciones.

Lo siento, no podría darte mejores noticias. Puede que haya más de un gurú aquí que pueda señalar una forma elegante de administrar el empaque, ¡y estaré tan interesado en usted como la respuesta! Puede enviarme un correo electrónico a suprasphere --- at --- gmail si desea compadecerse. :)

Answer 2

Recientemente hemos cambiado a usar 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 (especialmente en una cadena concat) que PrefixMgr.getObjPrefix() + ''MyObject__c'' .

Interesado en pensamientos y comentarios.