De Pesobook se han publicado varias versiones, y en este documento se exponen algunas experiencias con respecto al manejo de build and deploy de las distintas versiones de esta solución.
Pesobook tiene una interfaz Web HTML 5 + JS + CSS www.pesobook.com. Luego una app nativa iOS y otra nativa Android publicadas en Apple Store, Google Play y otros.
Pesobook tiene más de 100.000 usuarios, se ingresan unos 1000 pesos por día, cualquier downtime redunda en mails de quejas, que - hay que decirlo - son extremadamente pocas :)
Versiones: La web está en versión 2.0.3, la iOS en 3.0.1 y la Android en 3.0.
Usa autenticación GeneXus Access Manager (GAM) soportando usuarios anónimos.
Arquitectura: Las apps nativas tienen esta arquitectura: Online Native Mobile applications architecture. Así que se tienen los siguientes componentes: App nativa en iOS, App nativa en Android, Web y Servicios Rest en Ruby / Apache / Linux, Base de datos para GAM y para Pesobook en MySQL
De acuerdo al cambio que representa la versión nueva frente a la actual, puede haber incompatibilidades de la versión N+1 con la versión N tanto a nivel de base de datos como a nivel de servicios.
En alguna versión N+1 ha habido un cambio que llamamos "aditivo" en la base de datos: Se agregó un atributo. Ese atributo se agregó con NULLS=YES de forma que los programas de versión N puedan seguir funcionando.
En otro caso no fue posible y entonces teníamos tanto la base de datos N como la base de datos N+1 en el aire por un tiempo. Durante ese tiempo (varios meses) tuvimos que correr procedimientos de replicación de datos que pasaban los nuevos Pesos y otros datos de la BD versión N a la N+1 de forma que si un usuario empezaba a usar los programas N+1 tuviera ahí todos los cambios.
(El GAM correspondiente a la versión N lo configuramos de forma que no acepte nuevos usuarios, para así disminuir los problemas).
nomenclatura: Esos cambios que en su momento llamamos "aditivos" creo que se pueden llamar Backward compatible changes
También en los servicios REST que se exponen, hemos tenido tanto cambios aditivos como no aditivos. En el primer caso, se ha agregado un nuevo servicio. Este cambio se pudo entonces realizar sobre el mismo directorio virtual de la versión anterior.
En el caso de los cambios no aditivos en la versión N+1, siempre creamos un nuevo directorio virtual que luego apunta a la misma BD de la versión N.
Cambios no aditivos fueron: agregar un parametro a un procedimiento REST, agregar o quitar campos de un panel (que implica cambios en la cantidad de campos que el data provider REST correspondiente provee)
Hay cambios en la aplicación SD que solamente afectan su metadata, por ejemplo cambiar el color de la clase de un Theme. Estos cambios son considerados Minor Changes en GeneXus y fueron tratados como tales. Ver Native Mobile Versioning Details. No se requirió crear nuevo directorio virtual, simplemente se publicó el cambio y se hizo el cambio correspondiente en el numero de versión del Main.
Hay cambios en la aplicación SD que afectan metadata y servicios, por ejemplo un botón nuevo que llama a un procedimiento REST nuevo. Como el cambio de servicios es aditivo, también se puede tratar como minor change y se procede igual que en el caso anterior.
Cuando hay un arreglo en un user control, arreglos a crashes en los fuentes del flexible client (intérprete de la metadata), siempre subimos una nueva versión al Apple Store o Google Play simplemente.
Si el cambio es en una imágen, también. Pero si esta imágen cambia de nombre o se empieza a usar en más lados, entonces además hay un cambio en la metadata y debe ser tratado como se describe arriba.
A nivel de build & deploy, no fue trivial en el caso de Pesobook determinar si había cambios en la API Rest, ni si estos eran aditivos o no. Reorganizaciones hubo muy pocas y fueron acotadas, el conocimiento de si eran aditivas o no radicaba en los desarrolladores mismos.
El test de preproducción se facilitó durante los Upgrades de GeneXus X Evolution 2 desde que todas las propiedades de conexión de GAM (clientsecret, etc) se pueden configurar desde la KB, y se puede configurar que el GAM no se conecte a la BD durante el proceso de build.
Ver 2014-02-06 Acta Reunion - Build and Deploy