Configuración de model de compilation / deployment SVN para Sage SalesLogix Web Dev / UAT / Prod Instances

Estoy intentando configurar la architecture de control de origen de mi organización para nuestra aplicación web Sage SalesLogix. Estamos usando SVN.

Tenemos 3 serveres, un desarrollador, dos para las testings de aceptación del usuario y dos para la producción. Cada entorno tiene su propia database.

Nos gustaría mantener los troncos orderados, pero esto puede ser difícil cuando gestionamos el VFS de la manera en que SalesLogix quiere que lo hagamos.

Lo que me gustaría hacer es esto: – Hacer que todos los desarrolladores utilicen la instancia de installation de DEV de SalesLogix en App Arch. – Implementar cambios en máquinas locales para testings y revisiones de unidades locales. – Cuando se complete todo el trabajo de desarrollo, cree un set de todos los cambios en la revisión propuesta. – Un administrador de compilation instala el package en la instancia de installation de UAT. – Comstackr e implementar en carpetas UAT. – En caso de rechazo, desinstale el package y vuelva a instalarlo después de los cambios. – En la aceptación, haga lo mismo para los serveres de Producción y confirme los cambios.

Si bien esto significa que tenemos 3 VFS, significa que solo estamos desarrollando en uno, que para mí es el path a seguir.

¿Estoy en el path correcto en mi pensamiento?

Para ser sincero, no utilicé SVN para un model de SalesLogix, sino que uso Git exclusivamente con SalesLogix. Esto se debe a que la forma en que funciona Git se ajusta mejor a cómo funciona SalesLogix y Application Architect. En casos normales, el SCM no importa, pero sí lo hace con SalesLogix. No quiero decir que SVN no funcionará bien con un model de SalesLogix, sé que hay algunos que usan SVN con SLX (simplemente no será tan fácil como con Git o Mercurial), pero sinceramente, con las preferences de lado, el SalesLogix VFS / model realmente solo funciona bien con un SCM completamente distribuido.

Dicho esto, lo que describes es cómo trabajo con SalesLogix en Git. Trabajo creando una twig de desarrollo y hago todo mi trabajo allí. El maestro básicamente refleja lo que está en producción para que pueda volver a implementarlo en producción en cualquier momento desde el maestro si es necesario. En la twig de desarrollo, desarrollo todo y también creo twigs de características específicas. Luego, vuelva a fusionar cuando la function esté completa. Trabajar de esta manera le permite desarrollar y probar todo antes de moverlo a la twig de trabajo de producción. Una vez que esté listo para su implementación, puedo cambiar fácilmente a la twig de producción y luego implementar desde allí. Si el QA rechaza las cosas, solo es cuestión de volver a la twig de producción o retrotraer las confirmaciones si es necesario. Además, al trabajar de esta manera, solo necesita un único VFS o model. No tres separados como usted describe, ya que todo vive en twigs separadas y solo se fusionó con la twig maestra una vez que está completamente desarrollada y probada.

Con todo esto, sin embargo, sigo manteniendo sistemas de desarrollo y testing separados de la producción (principalmente porque trabajo como un socio comercial de SLX y no como un cliente de SLX), de lo contrario no hay manera de probar los packages para la entrega. En el sistema de desarrollo, uso la bifurcación descrita arriba para permitirme liberar arreglos en la producción mientras el desarrollo de nuevas características todavía está en marcha.

Desearía tener más información SVN específica para ti, pero los conceptos son los mismos independientemente de SCM utilizado.

Intereting Posts