Una fase importante en todo proyecto de Elun es la entrega, considerada tanto desde el constructor y/o proveedor hacia Elun y la que realiza Elun a si cliente externo. Esta debe certificar y dar confianza de que el trabajo fue realizado correctamente y se cumplen los estándares mínimos de calidad y buenas prácticas postulados en los capítulos anteriores.
Una vez aceptadas y probadas las piezas de software por parte del cliente, se deben realizar las actividades correspondientes de paso a producción alineadas con los lineamientos exigidos por Elun.
A continuación detallaremos las buenas prácticas solicitadas para las entregas y lanzamientos que requiere Elun.
Las entregas siempre deben ser formalizadas por e-mail por parte del jefe de proyecto del proveedor con el gestor de proyectos de Elun. Esta correo debe ser enviado en el día y hora pactado entre las contrapartes y debe contener:
Es obligación del jefe de proyecto externo el buscar la confirmación de entrega para cerrar dicho hito.
La revisión de las entregas por parte de Elun serán realizadas contra la solicitud realizada al proveedor, y se espera que de existir discrepancias, sean menores y decrecientes en el tiempo (nunca se esperamos que sean cero). En caso de existir entregas que no estén de acuerdo con el diseño inicial (tanto de software, de UI, u otro especificado) será responsabilidad del proveedor su corrección inmediata.
Es muy posible que durante el proceso de desarrollo se encuentren excepciones o casos de borde no contemplados. De ocurrir, estos se deben notificar de inmediatamente al gestor de proyectos Elun para su evaluación y acción correspondiente.
En caso de que se deba realizar la entrega con la excepción incluida, se deberá informar con detalle la naturaleza de la excepción, todas sus consecuencias para el caso junto con su posible acción correctiva. De esta forma tanto la entrega hacia Elun como hacia el cliente tendría sus puntos de fallas detectados y, de cierta medida, controlados.
Acá un ejemplo de lo anterior:
Caso: Se debe entregar una pieza de backend que implementará una función nueva en la App móvil.
Excepción detectada: Unos días antes de la entrega, el WS que provee el cliente dejó de funcionar.
Implementación sobre la excepción: Se implementó un componente mock que entrega una salida dummy del WS en cuestión.
Disclaimer de la excepción implementada: El mock implementado permite invisibilizar el actual problema de WS del cliente, pero limitará los escenarios de pruebas a realizar (el mock solo responde sobre los escenarios a, b y c). A pesar de ello, se podrán realizar los flujos en la aplicación móvil end-to-end. Es importante declarar esta excepción y sus consecuencias a los usuarios que realizarán las pruebas.
Cómo normalizar la excepción: Es necesario que el WS se estabilice. Una vez se reciba la confirmación de normalización por parte del cliente, se volverán a realizar pruebas por parte de Elun y se planificará una nueva entrega.
Disclaimer de gestión de proyecto: Desde la perspectiva de la planificación, el gap de tiempo generado por la implementación de la excepción deberá ser asumido como causa externa y no como responsabilidad de Elun. Los reajustes de tiempos y fechas serán revisados por los representantes de gestión de proyectos de ambas partes.
De igual forma que se deben tangibilizar entregas hacia Elun que generen confianza en el trabajo realizado, se debe traspasar esa misma confianza al cliente final.
En general, la comunicación con el cliente será encapsulada por el área de gestión de proyectos de Elun, por lo que podrían ser casos puntuales en que la jefatura de proyecto del proveedor tenga puntos de contacto con el cliente. Sin embargo, aunque no exista el contacto directo, es deber del proveedor poder entregar todos los insumos necesarios para tangiblizar una correcta entrega con los puntos anteriormente mencionados.
Tanto la herramienta de gestión de versiones como GitFlow juegan un rol clave en el ordenamiento del despliegue y su automatización.
Se establecerá que cada rama de GitFlow será la representante de cada entorno como se indica en el capítulo 3. Documentación y versionado. Los procesos de CI/CD serán configurados y mantenidos por el equipo de infraestructura de Elun para su utilización, pero será obligación del proveedor establecer un orden consistente de los releases a través de Pull Requests:
Para la definición de tags de versionado se debe seguir el indicado por Semantic Versioning 2.0.0.
A medida que se van liberando versiones, se deberá actualizar un documento de Changelog en que se indica:
Los pasos a producción serán mandatados y validados por Elun pero ejecutados por quienes correspondan según la definición de alcance de cada proyecto. Si se define dentro del marco comercial que el partner realizará la ejecución end-to-end del paso a producción, será responsabilidad de este la ejecución de los pasos y validación del correcto lanzamiento.
Como lineamiento de oro para los pasos a producción, siempre se deben considerar realizar los pasos a producción los primeros días de la semana y sobre todo no realizarlos los viernes.
Antes de poder preparar y calendarizar los pasos a producción, se debe obtener de manera explícita la confirmación por parte del cliente de que la pieza de software funciona correctamente según sus pruebas. Esto claro canalizado siempre a través del equipo de gestión de productos Elun.
Una vez se tenga la confirmación se podrá proceder con la planificación del paso a producción:
Es probable que por procesos propios de las áreas de operación TI de los clientes, haya que presentar y defender los planes de paso a producción. Esto será especificado según la naturaleza de cada proyecto.