Ciclo de desarrollo del Software - alfonsogastalverllamas/documentation GitHub Wiki

Full Software Development Life Cycle (SDLC)

🌀 1. Planificación (Planning)

¿Qué significa?

La planificación es la fase inicial del ciclo de desarrollo de software. Aquí se define qué se va a desarrollar, por qué es necesario, y cómo se va a abordar. Involucra a los stakeholders clave para entender necesidades, establecer objetivos y estimar los recursos necesarios.

Convenciones y conceptos clave

  • Stakeholders: Personas interesadas o afectadas por el sistema (clientes, usuarios, desarrolladores, etc.).
  • Estudio de viabilidad:
    • Técnica: ¿Tenemos la tecnología y habilidades necesarias?
    • Económica: ¿Es rentable?
    • Operativa: ¿Se puede integrar con los procesos actuales?
    • Legal: ¿Cumple con normativas y regulaciones?
  • Análisis de riesgos: Identificación de posibles obstáculos y planes de mitigación.
  • Roadmap: Hoja de ruta general del proyecto.
  • Estimación de esfuerzo: Se usa para calcular tiempos y costos (ej. en horas/hombre).
  • Scope (Alcance): Define los límites del proyecto.
  • Kick-off meeting: Reunión inicial para alinear expectativas.

Tecnologías y herramientas comunes

Python

  • Documentación: Notion, Confluence, Google Docs
  • Gestión de tareas: Jira, Trello, Asana
  • Estimación y planificación: Excel, Google Sheets, herramientas ágiles (Scrum boards)
  • Colaboración: Slack, Microsoft Teams

Java

  • Enterprise tools: Jira + Confluence (muy común en entornos corporativos)
  • UML con herramientas como Lucidchart o StarUML
  • Integración con IDEs como Eclipse o IntelliJ IDEA para sincronizar con sistemas de planificación

Otros lenguajes

  • JavaScript / Node.js: uso de Notion + Linear o Jira para planificación en proyectos web.
  • C# / .NET: Azure DevOps Boards, Microsoft Project.
  • Ruby: Basecamp, Trello.
  • Go: GitHub Projects, Notion.

🔍 Nota: La planificación no involucra código directamente, pero sí herramientas de gestión, documentación y estimación.

📋 2. Análisis de Requisitos (Requirements Analysis)

¿Qué significa?

Es el proceso de recopilar, entender, documentar y validar lo que el sistema debe hacer desde el punto de vista del usuario y del negocio. Esta fase establece la base para el diseño y desarrollo del software.

Convenciones y conceptos clave

  • Requisitos funcionales: Qué funcionalidades debe tener el sistema (ej. "el usuario puede registrarse").
  • Requisitos no funcionales: Cómo debe comportarse el sistema (ej. rendimiento, seguridad, usabilidad).
  • Historias de usuario: Formato ágil para describir necesidades:
    "Como [rol], quiero [función] para [beneficio]"
  • Casos de uso (Use Cases): Descripciones detalladas de interacciones entre actores y el sistema.
  • Diagrama de casos de uso (UML): Representa visualmente las interacciones.
  • Requisitos SMART:
    • Specific
    • Measurable
    • Achievable
    • Relevant
    • Time-bound
  • Priorización de requisitos: Ej. MoSCoW (Must, Should, Could, Won’t).

Tecnologías y herramientas comunes

Python

  • Documentación con Markdown, Notion, Confluence
  • Herramientas ágiles: Jira (con historias de usuario y épicas)
  • Modelado con diagramas: Draw.io, Lucidchart
  • Validación de requisitos: reuniones y validaciones con FastAPI prototipos rápidos

Java

  • Herramientas de modelado UML: StarUML, Enterprise Architect
  • Integración con Jira, Confluence
  • Documentación estructurada con plantillas IEEE
  • Requisitos capturados desde entrevistas, workshops y sesiones con clientes

Otros lenguajes

  • JavaScript / Node.js: Historias de usuario en Linear, Jira o GitHub Issues.
  • C# / .NET: Requisitos documentados en Azure DevOps Wiki o MS Word + SharePoint.
  • Ruby: Basecamp, Trello para requisitos ágiles.
  • Go: Documentación ligera, a menudo en Markdown y gestionada en GitHub o Notion.

✅ Importante: Esta fase requiere comunicación constante con usuarios finales, analistas y desarrolladores para garantizar que los requisitos estén claros y validados.

🧠 3. Diseño del Sistema (System Design)

¿Qué significa?

En esta fase se transforma lo que se definió en los requisitos en una solución técnica concreta. Se diseñan la arquitectura del sistema, la estructura de datos, los componentes, las interfaces y cómo interactúan entre sí.

Es el puente entre el "qué" (requisitos) y el "cómo" (implementación).

Convenciones y conceptos clave

  • Diseño de alto nivel (HLD - High Level Design):
    • Arquitectura general del sistema.
    • Componentes principales y cómo se comunican.
    • Diagrama de arquitectura (cliente-servidor, microservicios, etc.).
  • Diseño de bajo nivel (LLD - Low Level Design):
    • Detalles internos de cada componente.
    • Estructuras de datos, algoritmos, interfaces.
    • Diagramas de clases, secuencia, flujo de datos.
  • Principios SOLID: Buenas prácticas de diseño orientado a objetos.
  • Patrones de diseño (Design Patterns):
    • Ej: Singleton, Factory, Observer, MVC, etc.
  • Modelado UML:
    • Diagramas de clases, de secuencia, de actividad, de estados.
  • Arquitecturas comunes:
    • Monolítica, Cliente-Servidor, Microservicios, Serverless, Event-driven.

Tecnologías y herramientas comunes

Python

  • Arquitecturas típicas: MVC (Django), MVT (Flask, FastAPI), Microservicios con REST o gRPC.
  • UML: Lucidchart, Draw.io, PlantUML.
  • Design patterns: Uso común de Singleton, Factory, Adapter.
  • Herramientas: PyCharm, Visual Studio Code.

Java

  • Arquitecturas corporativas: Spring Boot con arquitectura hexagonal o DDD.
  • UML: StarUML, Enterprise Architect.
  • Frameworks: Spring MVC, Quarkus.
  • Patrones: Strategy, Builder, Factory ampliamente usados.
  • Documentación técnica en Confluence o documentos IEEE 1016.

Otros lenguajes

  • JavaScript / Node.js: Arquitectura basada en servicios, REST o GraphQL, MVC en frameworks como Express.js, Next.js.
  • C# / .NET: Clean Architecture, uso de patrones como Repository, CQRS.
  • Go: Diseño modular, enfoque minimalista, separación de capas manual.
  • Ruby: MVC en Ruby on Rails, uso de convenciones sobre configuración.

📐 Nota: Un buen diseño facilita el desarrollo, mantenimiento y escalabilidad del sistema.

🧱 Principios SOLID

Los principios SOLID son una guía para escribir código orientado a objetos más mantenible, flexible y escalable:

🔹 S – Single Responsibility Principle (Responsabilidad Única)

Una clase debe tener una sola razón para cambiar.
👉 Separa funcionalidades en clases distintas cuando sus propósitos no están alineados.

🔹 O – Open/Closed Principle (Abierto/Cerrado)

El software debe estar abierto para extensión, pero cerrado para modificación.
👉 Usa herencia o composición para extender funcionalidades sin alterar el código existente.

🔹 L – Liskov Substitution Principle (Sustitución de Liskov)

Una subclase debe poder sustituir a su superclase sin alterar el comportamiento del sistema.
👉 No violes contratos al extender clases.

🔹 I – Interface Segregation Principle (Segregación de Interfaces)

Las interfaces deben ser específicas para cada cliente, en lugar de genéricas y grandes.
👉 Prefiere muchas interfaces pequeñas a una sola muy grande.

🔹 D – Dependency Inversion Principle (Inversión de Dependencias)

El código debe depender de abstracciones, no de concreciones.
👉 Usa inyección de dependencias y define interfaces en lugar de acoplarte a implementaciones concretas.

🎨 Patrones de Diseño

Son soluciones probadas para problemas comunes en el diseño de software.

🔸 Creacionales

  • Singleton: Una sola instancia global.
  • Factory Method / Abstract Factory: Creación de objetos sin exponer la lógica de instanciación.
  • Builder: Construcción de objetos complejos paso a paso.
  • Prototype: Clonación de objetos.

🔸 Estructurales

  • Adapter: Hace que una clase funcione con una interfaz diferente.
  • Decorator: Añade responsabilidades a un objeto en tiempo de ejecución.
  • Facade: Proporciona una interfaz simplificada a un subsistema complejo.
  • Composite: Composición de objetos en estructuras de árbol.

🔸 Comportamiento

  • Observer: Notifica a múltiples objetos cuando cambia el estado de otro.
  • Strategy: Familia de algoritmos intercambiables en tiempo de ejecución.
  • Command: Encapsula una solicitud como objeto.
  • State: Cambia el comportamiento de un objeto según su estado interno.

📚 Recursos: Refactoring.Guru tiene excelentes explicaciones visuales y ejemplos.

🏗️ Arquitecturas Comunes

Diseños estructurales que definen cómo se organiza un sistema de software.

🔹 Monolítica

  • Toda la lógica está en un único proyecto o aplicación.
  • Más simple al inicio, pero difícil de escalar y mantener a largo plazo.

🔹 Cliente-Servidor

  • Separación clara entre cliente (frontend) y servidor (backend).
  • Comunicación por HTTP/REST, WebSocket, etc.

🔹 Microservicios

  • Cada componente del sistema es un servicio independiente que se comunica con otros vía APIs.
  • Escalable, independiente y desplegable por separado.
  • Requiere gestión de orquestación (Docker, Kubernetes) y comunicación robusta (REST, gRPC).

🔹 Arquitectura Hexagonal (Ports and Adapters)

  • Separa el núcleo de la aplicación (dominio) de sus entradas/salidas (UI, base de datos, etc.).
  • Facilita el testeo y la independencia de tecnologías externas.

🔹 Serverless

  • No se gestiona la infraestructura, solo se despliega código como funciones.
  • Escalabilidad automática, ideal para eventos y microprocesos.
  • Plataformas: AWS Lambda, Google Cloud Functions, Azure Functions.

🔹 Event-driven (Basado en eventos)

  • Los componentes reaccionan a eventos asincrónicos (mensajes, colas).
  • Alta escalabilidad y desacoplamiento.
  • Herramientas: Apache Kafka, RabbitMQ, AWS EventBridge.

🧩 Consejo: la arquitectura ideal depende del tipo de aplicación, volumen de usuarios, equipo de desarrollo y recursos disponibles.

💻 4. Desarrollo / Implementación (Development / Implementation)

¿Qué significa?

Es la fase en la que el equipo de desarrollo escribe el código fuente del sistema según lo especificado en el diseño. Aquí se construyen las funcionalidades del software, se integran módulos, se conectan con bases de datos, APIs, y se aplican buenas prácticas de programación.

Convenciones y conceptos clave

  • Control de versiones: Uso de sistemas como Git para gestionar cambios en el código.
  • Metodologías ágiles: Scrum, Kanban, XP. Desarrollo iterativo e incremental.
  • Branching models:
    • Git Flow
    • GitHub Flow
    • Trunk-Based Development
  • Buenas prácticas:
    • Código limpio (Clean Code)
    • Principios SOLID y DRY (Don’t Repeat Yourself)
    • Tests automáticos desde el inicio (TDD o al menos pruebas unitarias)
  • CI/CD: Integración y despliegue continuo para mantener la entrega fluida.

Tecnologías modernas por lenguaje

🐍 Python

  • Frameworks web: Django (MVT), Flask, FastAPI
  • ORMs: SQLAlchemy, Django ORM
  • Testing: pytest, unittest
  • Control de versiones: Git + GitHub/GitLab
  • CI/CD: GitHub Actions, GitLab CI, Jenkins
  • Entornos virtuales: venv, pipenv, poetry
  • Formatos de código y linters: black, flake8, mypy

☕ Java

  • Frameworks: Spring Boot, Jakarta EE, Micronaut
  • ORM: Hibernate, JPA
  • Testing: JUnit, Mockito
  • Build tools: Maven, Gradle
  • CI/CD: Jenkins, GitLab CI, GitHub Actions
  • IDE: IntelliJ IDEA, Eclipse
  • Estilo de código: Google Java Style, Checkstyle

🌐 Otros lenguajes

JavaScript / Node.js

  • Frameworks: Express, NestJS
  • Testing: Jest, Mocha
  • Package managers: npm, yarn
  • Herramientas: ESLint, Prettier, TypeScript
  • CI/CD: GitHub Actions, Vercel, Netlify

C# / .NET

  • Frameworks: ASP.NET Core
  • ORM: Entity Framework Core
  • Testing: xUnit, NUnit, MSTest
  • IDE: Visual Studio, Rider
  • CI/CD: Azure DevOps, GitHub Actions

Go

  • Estructura basada en módulos (go mod)
  • Pruebas con testing nativo
  • Uso fuerte de interfaces
  • CI con GitHub Actions o Drone
  • Herramientas: golangci-lint, go vet

⚙️ Nota: La implementación debe seguir el diseño aprobado, pero también adaptarse a mejoras emergentes siempre que se validen con el equipo.

🚀 Metodologías Ágiles

Las metodologías ágiles son enfoques para gestionar proyectos que priorizan la entrega continua de valor, la adaptabilidad al cambio y la colaboración constante con los usuarios. Se alejan de los modelos rígidos y secuenciales como el modelo en cascada.

🔹 Scrum

Scrum es un framework ágil que organiza el trabajo en sprints, iteraciones de tiempo fijo (1-4 semanas), en las que se entrega un incremento funcional del producto.

Roles clave:

  • Product Owner (PO): Representa al cliente o negocio. Prioriza el trabajo en el Product Backlog.
  • Scrum Master: Facilita el proceso, elimina obstáculos, entrena al equipo en Scrum.
  • Development Team: Grupo multidisciplinario que construye el producto.

Eventos de Scrum:

  • Sprint Planning: El equipo planifica qué tareas se realizarán en el sprint.
  • Daily Scrum: Reunión diaria de 15 minutos para sincronizar el equipo.
  • Sprint Review: Al final del sprint, se presenta el trabajo terminado a los stakeholders.
  • Sprint Retrospective: Reflexión del equipo sobre cómo mejorar el proceso.

Artefactos:

  • Product Backlog: Lista priorizada de funcionalidades (historias de usuario).
  • Sprint Backlog: Conjunto de tareas seleccionadas para el sprint actual.
  • Increment: Versión funcional y entregable del producto.

✅ Scrum es ideal para proyectos donde los requisitos cambian con frecuencia.

🔹 Kanban

Kanban es un método visual de gestión de tareas que se basa en la mejora continua, sin iteraciones fijas como en Scrum. Es más flexible y orientado al flujo.

Principios de Kanban:

  • Visualizar el flujo de trabajo: Usar un tablero con columnas (To Do, Doing, Done).
  • Limitar el trabajo en progreso (WIP): Para evitar cuellos de botella.
  • Gestionar el flujo: Observar y mejorar el tiempo que toma una tarea desde que inicia hasta que se completa.
  • Hacer políticas explícitas: Reglas claras para mover tareas entre columnas.
  • Mejora continua (Kaizen): Cambiar gradualmente el sistema para optimizar rendimiento.

🧠 Kanban es ideal para equipos de soporte, mantenimiento o entornos de trabajo impredecibles.

📐 Principios de Desarrollo

🔸 DRY – Don’t Repeat Yourself

Este principio busca evitar la duplicación de código. Todo fragmento de lógica debe tener una única representación clara en el sistema.

Ventajas:

  • Más fácil de mantener.
  • Menos errores al hacer cambios.
  • Código más limpio y legible.

Cómo aplicarlo:

  • Extraer lógica repetida en funciones, clases o módulos reutilizables.
  • Usar herencia o composición donde aplique.

🔸 TDD – Test-Driven Development (Desarrollo Guiado por Pruebas)

TDD es una técnica de desarrollo que consiste en escribir primero las pruebas antes del código funcional.

Ciclo de TDD:

  1. Red: Escribir una prueba que falle (porque la funcionalidad aún no existe).
  2. Green: Escribir el código mínimo necesario para que la prueba pase.
  3. Refactor: Mejorar el código manteniendo las pruebas en verde.

Ventajas:

  • Código mejor diseñado y desacoplado.
  • Mayor cobertura de pruebas.
  • Prevención temprana de errores.

Herramientas comunes:

  • Python: pytest, unittest
  • Java: JUnit, Mockito
  • JavaScript: Jest, Mocha
  • C#: xUnit, MSTest

🧪 TDD mejora la calidad desde el principio, aunque requiere disciplina y práctica.

🌳 Git y Git Flow

Git es el sistema de control de versiones más usado. Permite gestionar cambios de código y colaborar en equipo de manera segura y eficiente.

🔸 Git Flow

Git Flow es una estrategia de ramas muy usada en proyectos con despliegues regulares.

Ramas principales:

  • main (o master): contiene el código de producción.
  • develop: código en desarrollo, donde se integran nuevas funcionalidades.

Ramas de soporte:

  • feature/*: nuevas funcionalidades; parten de develop y se fusionan allí.
  • release/*: preparación de una versión; se crea desde develop.
  • hotfix/*: correcciones urgentes; parten de main y luego se integran en develop.

Ventajas:

  • Flujo claro para el equipo.
  • Aislamiento de cambios.
  • Facilita el versionado semántico.

Alternativas modernas:

  • GitHub Flow: para despliegues continuos; menos ramas, todo con pull requests a main.
  • Trunk-Based Development: todo se fusiona rápidamente a una rama principal, con feature flags.

🔄 CI/CD – Integración y Entrega/Despliegue Continuo

CI/CD es una práctica que automatiza la integración de código, la ejecución de pruebas y el despliegue de software.

🔹 CI – Continuous Integration

Proceso en el cual cada cambio de código es integrado automáticamente y verificado por pruebas automáticas.

Objetivos:

  • Detectar errores pronto.
  • Mantener una base de código estable.

🔹 CD – Continuous Delivery / Deployment

  • Delivery: El código está listo para desplegar en cualquier momento, pero el despliegue es manual.
  • Deployment: El código se despliega automáticamente tras pasar todas las pruebas.

Herramientas populares:

  • GitHub Actions
  • GitLab CI/CD
  • Jenkins
  • CircleCI
  • Travis CI
  • Azure DevOps Pipelines

Beneficios:

  • Menos errores en producción.
  • Feedback más rápido.
  • Despliegues frecuentes y seguros.

⚡ CI/CD convierte el desarrollo en un proceso fluido y confiable desde el commit hasta el despliegue final.

🧪 5. Pruebas (Testing)

¿Qué significa?

La fase de pruebas busca verificar y validar que el software funciona correctamente, cumple con los requisitos especificados y no presenta errores. Es una etapa crítica para garantizar la calidad, estabilidad y seguridad del producto antes (y después) de su despliegue.

🧰 Tipos de pruebas

🔹 Pruebas unitarias (Unit Testing)

Prueban pequeñas unidades del código, como funciones o métodos, de forma aislada.

Objetivo: Validar que cada componente individual funcione como se espera.

🔹 Pruebas de integración

Verifican que diferentes módulos o servicios funcionen correctamente cuando se combinan.

Ejemplo: Un controlador que recibe datos de un formulario y los guarda en la base de datos.

🔹 Pruebas funcionales

Evalúan si las funcionalidades del sistema cumplen los requisitos definidos.

Ejemplo: Probar que un usuario puede registrarse correctamente.

🔹 Pruebas de aceptación (UAT)

Realizadas por usuarios finales o clientes. Validan si el sistema satisface sus necesidades.

🔹 Pruebas de regresión

Aseguran que nuevos cambios no rompen funcionalidades ya existentes.

🔹 Pruebas de rendimiento (Performance/Load Testing)

Evalúan la estabilidad y velocidad del sistema bajo distintas cargas.

🔹 Pruebas automatizadas vs manuales

  • Automatizadas: Se ejecutan con scripts (rápidas, repetibles).
  • Manuales: Ejecutadas por testers humanos (útiles para UI y pruebas exploratorias).

🧪 Herramientas y frameworks de testing

Python

  • unittest (estándar)
  • pytest (flexible y potente)
  • tox, coverage para pruebas múltiples y cobertura de código

Java

  • JUnit (estándar)
  • Mockito (mocking para pruebas de integración)
  • TestNG, AssertJ

JavaScript / Node.js

  • Jest (todo en uno, rápido)
  • Mocha + Chai
  • Cypress, Playwright (E2E)

C# / .NET

  • xUnit, NUnit, MSTest
  • SpecFlow (BDD estilo Gherkin)
  • Selenium para pruebas UI

Go

  • Paquete testing integrado
  • testify, ginkgo, mockery

📋 Convenciones y buenas prácticas

  • AAA (Arrange, Act, Assert): estructura común de pruebas.
  • Cobertura de pruebas: Mide qué porcentaje del código ha sido probado.
  • Test pyramid: Favorecer más pruebas unitarias que E2E (más rápidas y específicas).
  • Naming claro: Los nombres de las pruebas deben expresar qué están verificando.
  • Evitar pruebas frágiles: Aquellas que fallan por cambios triviales o externos.

✅ Una buena estrategia de testing reduce errores en producción y aumenta la confianza del equipo.

🧪 Integración con CI/CD

  • Automatizar la ejecución de pruebas como parte del pipeline.
  • Bloquear despliegues si fallan las pruebas críticas.
  • Ejecutar pruebas en múltiples entornos o versiones.

🚦 Testing es un pilar clave de la entrega continua y del desarrollo profesional de software.

📋 Convenciones y buenas prácticas en testing

Las pruebas no solo deben existir, sino que deben seguir buenas prácticas para ser útiles, mantenibles y escalables.

🔺 La Pirámide de Pruebas (Test Pyramid)

La Test Pyramid es una metáfora visual que muestra cómo estructurar una estrategia de testing eficaz:

     UI Tests (E2E)
   ─────────────────
Integration Tests

─────────────────────── Unit Tests (la base)

1. Pruebas unitarias (base)

  • Muchas, rápidas, aisladas.
  • Detectan errores temprano.
  • Baratas de ejecutar.
  • Deben cubrir la lógica de negocio y unidades pequeñas de código.

2. Pruebas de integración

  • Menos cantidad que las unitarias.
  • Validan la interacción entre componentes: base de datos, servicios, APIs, etc.
  • Más costosas de mantener.

3. Pruebas end-to-end (E2E o UI)

  • Simulan acciones de un usuario real.
  • Lentas, frágiles, costosas.
  • Útiles para flujos críticos, no para probarlo todo.

✅ Regla general: muchas pruebas unitarias, menos de integración, y pocas E2E. Así maximizas eficiencia y confiabilidad.

🔧 Herramientas de automatización y verificación

No basta con escribir pruebas; también hay que automatizarlas, gestionarlas y analizarlas.

🔹 Frameworks por nivel de prueba

Tipo de prueba Python Java JavaScript C#/.NET Go
Unit testing pytest JUnit Jest, Mocha xUnit testing
Mocks/Stubs unittest.mock Mockito Sinon.js Moq mockery
Integration pytest-django, httpretty Spring Test Supertest TestServer httptest
E2E/UI testing Selenium, Playwright Selenium, Cucumber Cypress, Playwright SpecFlow chromedp
BDD behave Cucumber Jest-Cucumber SpecFlow godog

🔹 Herramientas de gestión y cobertura

  • Cobertura de código:

    • Python: coverage.py
    • Java: JaCoCo, Cobertura
    • JS: nyc, istanbul
    • .NET: coverlet
    • Go: go test -cover

  • Quality Gates / Revisión estática:

    • SonarQube: Analiza cobertura, duplicación, bugs y vulnerabilidades.
    • Codacy, Code Climate: Alternativas modernas y visuales.

  • Dashboards & informes:

    • Integraciones con Jenkins, GitHub Actions o GitLab para visualizar resultados.
    • Plugins de JUnit, Allure Reports, HTML reports.

🔁 Integración con CI/CD

🔹 Objetivo

  • Ejecutar las pruebas automáticamente tras cada push o pull request.
  • Detectar fallos antes de que el código llegue a producción.
  • Automatizar pasos como build, test, análisis estático y despliegue.

🔹 Herramientas de CI/CD comunes

✅ Jenkins

  • Potente, extensible, autohosteado.
  • Soporta jobs declarativos (Jenkinsfile) o freestyle.
  • Plugins para: JUnit, Docker, SonarQube, GitHub, Slack.
  • Integración con pytest, JUnit, Cypress, etc.

✅ GitHub Actions

  • Integración nativa con GitHub repos.
  • Workflows YAML para ejecutar pruebas en cada push o PR.
  • Matrix builds, test coverage, linting, etc.
  • Excelente para proyectos open source.

✅ GitLab CI/CD

  • Incluido en GitLab.
  • .gitlab-ci.yml define los pasos.
  • Soporta pipelines paralelos, testing por entorno o lenguaje.
  • Integración con Docker, Kubernetes, cobertura y seguridad.

✅ CircleCI

  • Fácil de usar, buena documentación.
  • Integración con repos de GitHub y Bitbucket.
  • Alta velocidad para proyectos con múltiples pasos.

✅ Azure DevOps Pipelines

  • Integración nativa para proyectos .NET.
  • Permite definir pipelines en YAML o visualmente.
  • Soporte para tests, despliegues y gates de calidad.

🔹 Ejemplo de flujo CI/CD con testing (GitHub Actions):

name: Run Tests

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: 3.11
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run tests
        run: pytest --junitxml=results.xml
      - name: Upload test report
        uses: actions/upload-artifact@v3
        with:
          name: test-results
          path: results.xml

🚀 6. Despliegue (Deployment)

¿Qué significa?

El despliegue es el proceso de liberar el software desarrollado a un entorno en el que los usuarios puedan interactuar con él, típicamente un entorno de producción. Puede incluir desde subir un sitio web hasta desplegar microservicios en la nube.

🧭 Tipos de entornos

  • Desarrollo (dev): Usado por desarrolladores para probar localmente.
  • Testing / QA: Ambiente para pruebas funcionales y de calidad.
  • Staging: Réplica del entorno de producción para validaciones finales.
  • Producción (prod): Entorno real donde los usuarios acceden al software.

📦 Estrategias de despliegue

🔹 Manual

  • Realizado por operadores, generalmente con scripts o pasos documentados.
  • Propenso a errores y no escalable.

🔹 Automatizado (Recomendado)

  • Usando pipelines CI/CD para automatizar el proceso.
  • Reproducible, seguro y más rápido.

🔹 Despliegue continuo (CD - Continuous Deployment)

  • Todo cambio aprobado pasa automáticamente a producción tras pasar pruebas.

🔹 Entrega continua (Continuous Delivery)

  • Cambios se integran y están listos para ser desplegados, pero se hace manualmente.

🌀 Estrategias de despliegue avanzadas

🔸 Rolling Deployment

  • Se actualiza una parte del sistema a la vez, sin tiempos de inactividad.

🔸 Blue/Green Deployment

  • Dos entornos activos (blue y green); uno sirve tráfico mientras el otro recibe la nueva versión.
  • Permite revertir fácilmente en caso de fallo.

🔸 Canary Release

  • Se lanza la nueva versión solo a un pequeño grupo de usuarios antes de expandir.

🔸 Feature Flags

  • Permiten activar o desactivar funcionalidades sin hacer un nuevo despliegue.
  • Útil para probar en producción sin riesgo.

☁️ Plataformas y tecnologías comunes

🔹 Contenedores y orquestación

  • Docker: Empaquetado del software en contenedores.
  • Docker Compose: Multi-contenedores en desarrollo.
  • Kubernetes: Orquestación de contenedores, escalabilidad, alta disponibilidad.

🔹 Cloud providers

  • AWS: EC2, ECS, EKS, Lambda, S3
  • Azure: App Services, Azure Kubernetes Service (AKS)
  • Google Cloud: Cloud Run, GKE, App Engine

🔹 Serverless

  • Despliegue de funciones sin gestionar servidores.
  • Ej: AWS Lambda, Google Cloud Functions, Azure Functions.

🔹 Plataformas de hosting modernas

  • Vercel, Netlify: Para frontend y APIs ligeras (Jamstack).
  • Render, Fly.io, Heroku: PaaS amigables para pequeños equipos y prototipos.

🔧 Herramientas de automatización y pipelines

Herramienta Tipo Ideal para
Jenkins CI/CD tradicional Flujos personalizados, entornos corporativos
GitHub Actions CI/CD Git-native Proyectos open source o integrados con GitHub
GitLab CI/CD Integrado en GitLab DevOps completo en un solo lugar
CircleCI CI/CD moderno Equipos ágiles, pipelines rápidos
ArgoCD GitOps (K8s) Deploys automáticos en Kubernetes
FluxCD GitOps (K8s) Integración continua vía Git con K8s

🧪 Buenas prácticas en despliegue

  • Automatizar todo el pipeline (CI + CD).
  • Usar infraestructura como código (IaC) con herramientas como Terraform o Pulumi.
  • Realizar despliegues en horarios de bajo tráfico.
  • Monitorear métricas de sistema post-despliegue.
  • Tener mecanismos de rollback claros.

🔁 Desplegar no debería ser un evento, sino una rutina automatizada y segura.

🔍 Ejemplo de pipeline básico de despliegue continuo

  1. git push al repositorio.
  2. GitHub Actions ejecuta:
    • Linter
    • Pruebas unitarias
    • Build del artefacto
    • Deploy automático a producción (Docker + Kubernetes)
  3. Notificación en Slack o Teams.
  4. Monitoreo activo tras despliegue.

☁️ La modernización del despliegue mejora la entrega de valor y reduce riesgos operativos.

🔧 7. Mantenimiento (Maintenance)

¿Qué significa?

El mantenimiento es la fase posterior al despliegue, donde se asegura la operatividad, estabilidad y evolución del software a lo largo del tiempo. Es una etapa continua que puede durar años, mucho más que el desarrollo inicial.

🛠️ Tipos de mantenimiento

🔹 Mantenimiento correctivo

  • Solución de errores detectados en producción.
  • Puede incluir hotfixes, parches o cambios en lógica.

🔹 Mantenimiento adaptativo

  • Cambios necesarios para adaptar el software a nuevos entornos, versiones de sistemas operativos, navegadores, etc.

🔹 Mantenimiento perfectivo

  • Mejoras funcionales, refactorizaciones, optimizaciones de rendimiento.
  • Cambios sugeridos por feedback de usuarios o evolución del negocio.

🔹 Mantenimiento preventivo

  • Acciones que reducen el riesgo de futuros errores: limpieza de código, actualización de dependencias, pruebas de regresión, etc.

🧰 Herramientas y estrategias comunes

🔸 Monitoreo y observabilidad

  • Logs: Captura de eventos clave de la aplicación.
    • Herramientas: Logstash, Fluentd, Papertrail.
  • Métricas: Rendimiento, uso de recursos, tiempos de respuesta.
    • Herramientas: Prometheus, Grafana, Datadog, New Relic.
  • Alertas: Notificaciones automáticas ante fallos.
    • Herramientas: Grafana, PagerDuty, Opsgenie.

🔸 Gestión de errores y trazabilidad

  • Captura automática de excepciones y errores en tiempo real.
    • Herramientas: Sentry, Rollbar, Raygun, Bugsnag.

🔸 Actualización de dependencias

  • Automatización de revisión de librerías desactualizadas o vulnerables.
    • Herramientas: Dependabot (GitHub), Renovate, Snyk.

🔸 Documentación técnica continua

  • Mantener actualizados diagramas, endpoints, decisiones técnicas.
  • Herramientas: Confluence, Notion, Swagger/OpenAPI.

🧪 Testing post-despliegue

  • Pruebas de regresión automatizadas para detectar roturas al modificar código existente.
  • Pruebas periódicas de seguridad (penetration testing, análisis estático).
  • Validación continua de rendimiento y estabilidad.

👥 Soporte al usuario y feedback

  • Sistema de tickets para registrar y atender problemas (Jira Service Desk, Zendesk, Freshdesk).
  • Canales de retroalimentación para mejorar el producto (encuestas, reviews, foros).
  • Análisis de uso para priorizar futuras mejoras (Hotjar, Mixpanel, Google Analytics).

💡 Buenas prácticas de mantenimiento

  • Automatizar tareas repetitivas (scripts, bots, cron jobs).
  • Refactorizar regularmente para mantener el código limpio.
  • Evitar la deuda técnica: no postergar arreglos importantes.
  • Planificar mantenimientos programados y comunicarlos a los usuarios.
  • Auditorías y revisiones periódicas de seguridad y arquitectura.

🔄 El mantenimiento no es un costo extra, es una inversión para que el software siga generando valor a lo largo del tiempo.