Introbook: Construcción y Despliegue

Esta área se enfoca en la automatización de los procesos de construcción del software, las pruebas y su despliegue en los diferentes entornos. La automatización busca agilizar la entrega, reducir errores humanos y aumentar la frecuencia de las liberaciones.

1. Integración continua

La integración continua (CI) es una práctica de desarrollo de software en la que los desarrolladores integran su código en un repositorio compartido de manera frecuente. Este proceso ayuda a detectar errores y mejorar la calidad del software al permitir una gestión más eficiente del código y permitir pruebas automáticas.

Acciones

• Nivel 1:
• Integración continua con pipeline estándar (que realice la compilación, un análisis estático y ejecute las pruebas unitarias) sobre rama Develop.
• Integración continua con pipeline estándar (que realice la compilación, un análisis estático y ejecute las pruebas unitarias) sobre rama Main.
• Nivel 2:
• Integración continua con pipeline estándar (que realice la compilación, un análisis estático y ejecute las pruebas unitarias) sobre las ramas no principales adoptadas de acuerdo a la metodología.
• Análisis estático configurado en el pipeline. El resultado del Quality Gate se informa en el pipeline o lo deja inestable.
• Análisis en el pipeline de vulnerabilidades en artefactos externos o imágenes de contenedores. Con impacto (fallo/inestable) si se introducen nuevas vulnerabilidades
• El pipeline se impacta (falla/inestable) si no se alcanza el Quality Gate establecido
• Nivel 3:
• La definición del proceso IC está versionada y en el SCV. IC con enfoque as code (Jenkinsfile, yaml, etc)
• Pruebas unitarias automáticas integradas en el pipeline e impacto al no cumplir con el porcentaje de cobertura mínimo.
• Pruebas funcionales ejecutadas automáticamente integradas en el pipeline con impacto y visualización de resultados

2. Estrategia de ejecución del pipeline

Definir cómo se orquestan y ejecutan los diferentes pasos dentro de un pipeline de CI/CD (construcción, pruebas, análisis de seguridad, despliegue, etc.). Esto incluye la definición de los triggers, las etapas, los flujos de trabajo y las herramientas utilizadas en cada fase.

3. Entrega continua

Extiende la integración continua automatizando el proceso de preparación para la liberación del software a los entornos de desarrollo o prueba. Implica que el software está siempre en un estado potencialmente desplegable basado en las ramas de integración definidas.

4. Despliegue continuo

Va un paso más allá de la entrega continua, automatizando el despliegue del software a los entornos de producción después de que ha pasado por todas las etapas de pruebas y validaciones.

Introbook: Versioning

Esta área se centra en la gestión y el seguimiento de los cambios realizados a lo largo del ciclo de vida del desarrollo de software y la infraestructura. Un versionamiento adecuado es fundamental para la colaboración, la trazabilidad y la capacidad de revertir cambios en caso de ser necesario.

1. Control de versiones del código fuente

El uso de sistemas de control de versiones (como Git) para gestionar los cambios en el código fuente de las aplicaciones. Permite llevar un historial de modificaciones, colaborar de manera eficiente entre desarrolladores, crear ramas para el desarrollo de nuevas funcionalidades o correcciones, y fusionar los cambios de forma controlada.

Acciones

• Nivel 1:
• Se cuenta con alguna herramienta para control de versiones de código fuente.
• Nivel 2:
• Se realiza sincronización de código asegurando que todos trabajen sobre la versión más reciente (uso de pulls y pushes regulares).

Qué es Git

Es un software de control de versiones, su propósito es llevar registro de los cambios en archivos de computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos (También puedes trabajar solo no hay problema). Existe la posibilidad de trabajar de forma remota y una opción es GitHub. 

Flujo de trabajo con Git

Tenemos nuestro directorio local (una carpeta en nuestro pc) con muchos archivos, Git nos irá registrando los cambios de archivos o códigos cuando nosotros le indiquemos, así podremos viajar en el tiempo retrocediendo cambios o restaurando versiones de código, ya sea en Local o de forma Remota (servidor externo). 

¿Qué es GitHub?

Es una plataforma de desarrollo colaborativo para alojar proyectos (en la nube) utilizando el sistema de control de versiones Git.

Comando esenciales

2. Gestión de ramas

En la gestión de ramas de código, las ramas actúan como indicadores ligeros que permiten separar y organizar el trabajo en desarrollo. Una vez que se completa una tarea en una rama específica, es fundamental fusionar estos cambios de vuelta a la rama principal del equipo. Aunque existen diversas metodologías válidas para llevar a cabo este proceso, es crucial contar con una estrategia bien definida que sea comprendida por todos los miembros del equipo. Esto asegura una colaboración eficiente y un flujo de trabajo más organizado dentro del entorno de DevOps.

Acciones

• Nivel 1:
• Se cuenta con una estrategia de gestión de ramas conocida por todo el equipo y que cubre las necesidades del proyecto (GitHub Flow, Streamline, Gitflow, Trunk-Based Development o alguna metodología similar).
• Nivel 2:
• Borrado de ramas al integrar con ramas principales
• Nivel 3:
• Uso de etiquetas (tag) en la rama principal
• Uso de merge/pull requests

Links

• Metodologias Git flow y trunk based
• Todos contra master: Trunk-Based Development
• Trunk Based Development principios y recomendaciones desde la trinchera
• ¿Qué es Trunk-Based Development?
• La estrategia de ramas de vida corta explicada
• Gitflow explicado paso a paso
• Domina las Feature Branches con esta guía paso a paso

3. Control de versiones de entregables

El versionado de entregables es un aspecto fundamental en la gestión de proyectos de desarrollo de software, ya que permite mantener un control claro sobre las diferentes versiones de un producto a lo largo de su ciclo de vida. Este proceso no solo ayuda a identificar y organizar las actualizaciones de las funcionalidades, sino que también facilita la reversibilidad en caso de que surjan problemas con nuevas versiones.

4. Gestión de artefactos

La gestión de artefactos es un proceso crucial en el desarrollo de software que se refiere a la organización, almacenamiento y control de los diversos productos generados durante el ciclo de vida del proyecto. Estos artefactos pueden incluir código fuente, librerías, documentación, configuraciones y

cualquier otro componente que sea relevante para la construcción y despliegue del software. Implementar prácticas efectivas de gestión de artefactos para asegurar que todos los miembros del equipo tengan acceso a las versiones correctas y actualizadas de los mismos, así como para facilitar la trazabilidad y el control de cambios.

Prácticas técnicas de DevOps

 

El gráfico muestra un flujo completo de prácticas técnicas de DevOps, organizado como una cadena de 10 etapas conectadas entre sí. Representa el ciclo de vida del software, desde el código hasta la operación y mejora continua.

1. Versionamiento

Aquí se controla todo lo relacionado con el código y sus cambios.

• Control de versiones del código fuente
• Gestión de ramas
• Control de versiones de entregables
• Gestión de artefactos

👉 Es la base para trabajar en equipo sin conflictos.

---

2. Construcción y Despliegue

Se enfoca en automatizar la entrega del software.

• Integración continua (CI)

• Estrategias de ejecución de Pipelines

• Entrega continua (CD)

• Despliegue continuo

👉 El objetivo es entregar rápido y de forma confiable.

---

3. Bases de Datos

Gestiona los cambios en la base de datos.

• Versionado y control de cambios de BD

👉 Evita errores cuando el esquema cambia entre entornos.

---

4. Aseguramiento de Calidad

Busca validar que el sistema funcione bien.

• Pruebas unitarias

• Pruebas funcionales

• Pruebas de rendimiento

👉 Aquí se detectan errores antes de llegar a producción.

---

5. Mantenibilidad de Código

Se centra en la salud del código a largo plazo.

• Gestión de deuda técnica

👉 Código limpio = menos problemas en el futuro.

---

6. Aprovisionamiento de Entornos

Automatiza la infraestructura.

• Gestión de entornos

• Configuración como código

• Infraestructura como código (IaC)

👉 Todo reproducible y sin configuraciones manuales.

---

7. Seguridad

Integra la seguridad en el proceso.

• Análisis estático

• Análisis dinámico

👉 Seguridad desde el inicio (DevSecOps).

---

8. Reportes y Monitoreo

Permite observar el sistema en producción.

• Reportes

• Monitoreo

👉 Detecta fallos y mejora la estabilidad.

---

9. Documentación de Calidad

Asegura que el conocimiento no se pierda.

• Gestión del conocimiento

👉 Facilita el mantenimiento y el onboarding.

---

10. GenAI

Incorpora inteligencia artificial en el proceso.

• Diseño

• Desarrollo

• Pruebas

• Seguridad

👉 Apoyo inteligente para acelerar y mejorar el desarrollo.

A Philosophy of Software Design - John Ousterhout

 

Create Azure App - Practice Tests

 

Instrument solutions to support monitoring and logging - Practice Tests

 

Por qué la documentación debe vivir junto al código

Esa idea proviene de una práctica común en ingeniería de software y desarrollo ágil.

Martin Fowler — En sus artículos sobre "Self-Documenting Code" y "Continuous Integration", Fowler sugiere que la documentación debe estar “lo más cerca posible del código” para mantenerse actualizada y  Fowler promueve documentar dentro del código (por ejemplo, con comentarios o docstrings), o en el mismo repositorio (por ejemplo, usando README o Markdown junto al código fuente).

Kent Beck — En Extreme Programming Explained, Beck también insiste en que la mejor documentación es el código mismo, y que cualquier documentación adicional debe estar “junto al código que describe” para evitar que quede obsoleta.

Joel Spolsky — En su ensayo “Where does documentation live?”, Joel recomienda mantener la documentación cerca del código en el control de versiones, por la misma razón: coherencia y mantenimiento.