Proceso de Publicación de Aplicaciones

En la siguiente imagen se muestran las acciones que forman parte del proceso de publicación de aplicaciones, además de la acción previa que debe hacerse para poder iniciar el proceso.

<osam_proces_de_publicacio_dapps

A continuación se detallan estas acciones

1. Validación Jefe de Proyecto OSAM de la versión de desarrollo

Todas las aplicaciones móviles del Ayuntamiento tendrán asignado un jefe de proyecto de la OSAM, que dará soporte y acompañará el desarrollo y publicación de la misma. El jefe de proyecto de la OSAM (en adelante JdP OSAM) validará durante el desarrollo de la versión que ésta cumpla los requisitos técnicos para el desarrollo de aplicaciones para el Ayuntamiento de Barcelona, y en caso de no ser así, lo comunicará al proveedor de la aplicación para que realice las acciones correctivas necesarias.

Sólo cuando la versión de desarrollo ha sido validada por el JdP OSAM ésta podrá pasar al proceso de publicación.

2. Completar información de la app en Palantir Mobile

La OSAM usa la herramienta propia Palantir Mobile para gestionar toda la información necesaria para la publicación de las versiones en los markets. Se puede consultar más información sobre Palantir en este manual.

En este paso deben hacerse las siguientes acciones:

  • El proveedor de la aplicación debe subir el código de la versión al repositorio indicado por la OSAM, y deberá crear una ficha con toda la información de la versión a publicar en Palantir. Esta información se usará para la publicación.
  • La persona responsable de la aplicación debe validar en Palantir que la información no técnica introducida es correcta. Campos como las novedades de la versión, la descripción, etiquetas, etc.
  • El JdP OSAM asignado a la aplicación será el responsable de proporcionar los accesos a Palantir para el proveedor y el responsable.

 

Una vez la información está completa y validada en Palantir, se inicia el SLA para el envío de la versión al market para su validación.

3. Validación de las versiones de producción

Con la información de Palantir, el código de la versión que ha subido el proveedor será compilado automáticamente con los códigos del Ayuntamiento (códigos como la key de Google Analytics, etc.). Durante este proceso también se realizan varias valoraciones para validar que la versión cumple con los requisitos. Finalmente, se enviará un mail con el resultado de la compilación, y si todo es correcto, se distribuirá la versión al proveedor y al responsable para que validen que no hay ningún problema.

Si se detecta algún error durante la validación automática realizada durante la compilación, es decir, si la versión no cumple algún requisito, se deberá volver a iniciar el proceso de publicación. Se debe tener en cuenta esta situación en la planificación del proyecto.

En esto paso deben hacerse las siguientes acciones:

  • La persona responsable de la aplicación deberá validar el correcto funcionamiento de la versión.
  • El proveedor de la aplicación deberá validar el correcto funcionamiento de la versión.
  • Si el responsable y el proveedor consideran que la versión es correcta, se puede seguir con el proceso de publicación. Si no es así, deberá iniciarse de nuevo el proceso de publicación.

4. Informe de calidad

Las nuevas versiones de las plataformas Android y IOS pasarán un proceso de test interno (smoke test) para medir la calidad de las mismas previamente a la publicación en los markets.

Los objetivos principales de este smoke test son los siguientes:

  • Validar el cumplimiento de las guidelines de desarrollo y calidad establecidas en los diferentes markets de aplicaciones vigentes en el momento de la publicación. Aunque la responsabilidad de este cumplimiento será del desarrollador de la aplicación.
  • Certificar la compatibilidad de la aplicación en las diferentes versiones de sistemas operativos, dispositivos y operadores de telefonía para garantizar un % mínimo de cobertura de mercado.

En función de la complejidad de la aplicación se realizará adicionalmente una prueba real de funcionamiento mediante un test de estabilidad y de carga en entornos productivos.

1) La OSAM proporcionará al proveedor un documento de alcance del smoke test para preparar adecuadamente esta fase.

En caso de identificar incidencias en esta fase se categorizarán en:

  • Errores graves: cualquiera de estas impide la publicación de la app hasta ser resueltas en una nueva entrega del código.
  • Errores leves: deberán ser resueltas en futuras versiones de la app.

2) La OSAM devolverá un informe como resultado de esta fase, que se enviará a la persona responsable de la aplicación y al proveedor. Este informe puede tener estos resultados:

  • Conformidad: La versión contiene de 0 a 3 errores leves.
  • Conformidad, pero con la publicación no recomendada por la OSAM: La versión contiene más de 3 errores leves. En este caso, la recomendación de la OSAM es realizar un nuevo desarrollo corrigiendo los errores antes de realizar la publicación, y se preguntará al responsable de la aplicación si quiere adelante con su publicación. Sólo se publicará la versión con su conformidad expresa.
  • No conformidad: La versión contiene uno o más errores graves.

En caso de no conformidad del test, la versión será devuelta al proveedor para su resolución. Hay que tener en cuenta esta situación en la planificación del proyecto.

5. Validación de la versión por los Markets

En esta fase, la OSAM a través de la información introducida en el Palantir completará las fichas de los diferentes Markets y tramitará su validación. La OSAM no incorporará ninguna información a los Markets que no esté grabada en el Palantir.

El tiempo de validación de los diferentes Markets depende de cada plataforma. Tanto para la Apple Store como para la Play Store no hay ningún compromiso de tiempo de validación de las aplicaciones que puede afectar al tiempo de publicación total.

En caso de que la validación de la aplicación por parte de los markets sea desfavorable, habrá que volver a iniciar todo el proceso de publicación, y generar una nueva versión bajo la responsabilidad del proveedor. Hay que tener en cuenta esta situación en la planificación del proyecto.

6. Liberación de la versión en los Markets

En esta fase, una vez validada la aplicación por parte de los Markets, la OSAM se pondrá en contacto con el responsable de la aplicación para autorizar la liberación de la versión para la descarga por parte de los usuarios. En el caso que se retrase la liberación de la versión, puede ser necesario realizar de nuevo el smoke test o incluso se puede cancelar la publicación al haber caducado la versión, tal y como se explica en el apartado 3. Caducidad de las versiones preparadas para publicar.

Esta tarea puede tardar aproximadamente 2 horas y con un máximo de 24 h dependiendo de la plataforma.

La OSAM realizará una prueba de descarga para validar el correcto funcionamiento de descarga / actualización de las versiones, y en las 24 h siguientes a la publicación de la app también se realizará un proceso de test (market test), similar al realizado en la fase de test interno, donde se revisará el funcionamiento general de la versión y se comprobará que el resultado es igual al del smoke test.

En caso de identificar incidencias, estas se categorizarán como en el smoke test.

La OSAM devolverá un informe como resultado de este test, que se enviará a la persona responsable de la aplicación y al proveedor. Este informe incluirá: Informe de market test: resumen de resultados, comentarios y conformidad del test.

En caso de no conformidad del test, habrá que volver a iniciar todo el proceso de publicación, y generar una nueva versión bajo la responsabilidad del proveedor. Será decisión de la persona responsable y el JdP OSAM despublicar la versión publicada.