Dado que cada organización generalmente tiene diferentes niveles de entornos, estructura organizativa o procedimientos de desarrollo, sugiero mantenerlo básico. Si su libro está destinado a diseñadores, también sugeriría un diagrama visual o de flujo. No tiene que ser detallado para cubrir todo tipo de proceso de implementación potencial, o incluso cubrir todos los componentes técnicos que intervienen en empujar, reiniciar servicios, etc. Consideraría resaltar lo siguiente:
- Desarrollo en entornos locales utilizando algo como git para verificar las ramas de los repositorios, realizar cambios o agregar nuevas funcionalidades (esto podría ser código front-end o back-end). Recargar o volver a ejecutar el código dentro de este entorno para iterar y probar. Para los diseñadores, aquí es donde generalmente se sientan con el ingeniero y ajustan y ajustan el código juntos.
- Impulsar cambios en el repositorio que pueden ser verificados, evaluados y probados por otros ingenieros para la revisión del código.
- Empujar esa rama o repositorio y lanzar a un entorno de prueba para que otros realicen pruebas adicionales, o pruebas de integración más pesadas con la funcionalidad existente u otra funcionalidad nueva de otros ingenieros o equipos. Esto es típicamente donde los diseñadores, ingenieros y otros miembros de la organización, y algunas veces incluso clientes seleccionados, pueden probar y demostrar todo.
- Empujar y soltar a un entorno de preparación para el control de calidad final. Aquí es donde entran las últimas pruebas y aprobaciones. Cuando pasa aquí, está listo para enviar.
- Lanzamiento a producción. Ya sea durante un tiempo de lanzamiento planificado o si está implementando continuamente, aquí es donde el código afecta a la mayoría de los usuarios (o a un subconjunto de usuarios, si tiene un marco de prueba habilitado para implementar nuevas características lentamente) y el trabajo es ‘ Enviado’
