Versionamiento de software

Transcript

1. Desarrollo de Software De los mainframes al CI/CD: Cómo DevOps nació de 30 años de caos y aprendizaje Abraham Zamudio https://www.linkedin.com/in/abraham-zamudio/
2. El desarrollo de software hace referencia a un conjunto de actividades informáticas dedicadas al proceso de creación, diseño, implementación y soporte de software. ¿Qué es el desarrollo de software? 01 El software propiamente dicho es el conjunto de instrucciones o programas que indican a un ordenador lo que debe hacer. Es independiente del hardware y hace que los ordenadores sean programables. Hay tres tipos básicos: Software de sistema, que proporciona funciones básicas, como sistemas operativos, gestión de discos, servicios, gestión de hardware y otras necesidades operativas. Software de programación, que proporciona herramientas a los programadores, como editores de texto, compiladores, enlazadores, depuradores y otras herramientas para crear código. Software de aplicación (aplicaciones o apps), que ayuda a los usuarios a realizar tareas. Por ejemplo, conjuntos de productividad ofimática, software de gestión de datos, reproductores multimedia y programas de seguridad. Las aplicaciones también se refieren a aplicaciones web y móviles como las que se utilizan para comprar en Amazon.com, socializar con Facebook o publicar fotos en Instagram. Un posible cuarto tipo es el software embebido. El software de sistemas embebidos se utiliza para controlar máquinas y dispositivos que normalmente no se consideran ordenadores: redes de telecomunicaciones, automóviles, robots industriales, etc. Estos dispositivos, y su software pueden conectarse como parte del Internet de las cosas (IoT).
3. Seleccionar una metodología para establecer un marco en el que se apliquen los pasos del desarrollo de software. Implica describir un proceso de trabajo global o una hoja de ruta para el proyecto. Las metodologías pueden incluir el desarrollo ágil de software, las prácticas DevOps, el desarrollo rápido de aplicaciones (RAD), el marco Scaled Agile Framework (SAFe), el desarrollo en cascada y más. Recopilar requisitos para comprender y documentar lo que necesitan los usuarios y otras partes interesadas. Elegir o construir una arquitectura como estructura subyacente dentro de la cual operará el software. Desarrollar un diseño en torno a soluciones a los problemas presentados por los requisitos, lo que a menudo implica modelos de procesos y guiones gráficos. Pasos en el proceso de desarrollo de software 0 2 Crear un modelo con una herramienta de modelado que utilice un lenguaje de modelado como SysML o UML para llevar a cabo la validación temprana, la creación de prototipos y la simulación del diseño. Construir código en el lenguaje de programación adecuado. Implica la revisión por pares y en equipo para eliminar problemas de forma temprana y producir software de calidad más rápido. Realizar pruebas con escenarios planificados de antemano como parte del diseño y la codificación del software, y realizar pruebas de rendimiento para simular pruebas de carga en la aplicación. Gestionar la configuración y los defectos para comprender todos los artefactos del software (requisitos, diseño, código, pruebas) y crear distintas versiones. Implica establecer prioridades de control de calidad y criterios de publicación para abordar y hacer un seguimiento de los defectos.
4. Implementar el software para su uso y resolver los problemas de los usuarios. Migrar datos al software nuevo o actualizado desde aplicaciones o fuentes de datos existentes, si es necesario. Gestionar y medir el proyecto para mantener la calidad y la entrega a lo largo del ciclo de vida de la aplicación, y evaluar el proceso de desarrollo con modelos como el Modelo de Madurez de Capacidades (CMM). Pasos en el proceso de desarrollo de software 03
5. El pasado: “El Software era un evento” (1990s–2000s) El desarrollo de software en la línea del tiempo 04 📌 Ejemplo real: Un bug en una app de banca requirió 4 semanas para corregirse porque había que llenar 17 formularios y esperar auditoría. 🔥 Resultado: Lanzamientos dolorosos, miedo al cambio, “operaciones” como custodios del infierno.
6. • Internet se volvió crítica: Apps no son productos, son servicios. • Clientes quieren cambios diarios: Netflix lanza 1000 veces al día. • La nube llegó: AWS, Azure → No necesitas servidores físicos. ¡Puedes crearlos con código! • Móvil + Big Data + Microservicios: Arquitecturas complejas → ¡Ya no puedes hacerlo todo manual! La ruptura: ¿Qué cambió en los 2010s? 05 ⚠ Problema nuevo: Si tienes 50 microservicios, ¿cómo aseguras que todos funcionen juntos? ¿Cómo sabes si un cambio en el servicio de pago rompe el carrito de compras? ✅ Respuesta emergente: Automatización. Integración. Observabilidad. → DevOps no es una herramienta. Es una cultura de respuesta rápida y confiable.
7. DevOps = Desarrollo + Operaciones + Cultura + Automatización 🔹 Objetivo: Lanzar software seguro, rápido y sostenible — muchas veces al día. 🔹 No es solo usar Docker o Jenkins. Es: • Que el desarrollador entienda lo que pasa en producción. • Que el operador entienda cómo se construye el código. • Que todos compartan la responsabilidad del éxito del sistema. Si tú escribiste el código, también debes ayudar a mantenerlo vivo. ¿Qué es DevOps? (Definición simple, sin jerga) 06
8. Pythonistas: Ya usan automatización (scripts, pytest). DevOps es llevar eso al nivel de producción. Los pilares de DevOps (el “CAMPS” simplificado) 07
9. Imagina que hiciste un script en Python que procesa datos de ventas: El flujo DevOps moderno (con tu código Python como ejemplo) 08 Flujo DevOps típico: 1. Codificas → Subes a GitHub (git push) 2. CI (Integración Continua) → → Se ejecutan tests: pytest test_sales_analyzer.py → Se chequea estilo: black, flake8 → Se empaqueta en Docker: docker build -t sales-app . 3. CD (Entrega Continua) → → Si pasa todo, se sube a AWS Lambda o ECS → Se notifica a Slack: “✅ Deploy exitoso en staging” 4. Monitoreo → → Prometheus alerta si el tiempo de procesamiento supera 5s → Datadog muestra métricas en dashboard 5. Feedback → → Un usuario reporta un error → Tu PR se reabre en 10 minutos # sales_analyzer.py import pandas as pd def analyze_sales(file): df = pd.read_csv(file) return df.groupby('region').sum() ¡Todo esto puede hacerse con Python + GitHub Actions + Docker + AWS!
10. Herramientas clave que DEBES conocer (y cómo Python las usa) 09
11. DevOps te convierte en dueño de tu trabajo. No eres solo un programador. Eres un ingeniero de sistemas. ¿Por qué DevOps te beneficia a ti, como desarrollador Python? 10
12. • Copilotos de código (GitHub Copilot): Sugieren tests, Dockerfiles, incluso pipelines. • IA monitorea logs: “Este error aparece cuando el CSV tiene columnas faltantes — sugiero validar antes.” • Automatización predictiva: “Tu último commit aumentó el uso de memoria. ¿Quieres optimizarlo?” • Auto-healing: “El contenedor cayó. Lo reinicié. Aquí está el root cause.” El futuro cercano: DevOps + IA Generativa 11 En 2025, el buen devops no será quien sabe configurar Jenkins… sino quien sabe guiar a la IA para que haga lo correcto.
13. Acciones inmediatas (Ya obtenido el super poder de ser autodidacta): 1. Automatiza un test en tu proyecto Python con GitHub Actions. 2. Empaqueta tu app en Docker — aunque sea un “hello world”. 3. Lee 1 artículo sobre “Observability” (no sobre Kubernetes). 4. Habla con tu equipo de operaciones — pregúntales: “¿Qué te molesta más de nuestros lanzamientos?” Conclusión — Tu próximo paso 12
14. Versionamient o de software Abraham Zamudio https://www.linkedin.com/in/abraham-zamudio/
15. • Control de versiones (CVS) = El “undo” del desarrollo de software. • Sin él: → Archivos como app_v2_final_FINAL_really_final.py → “¿Quién cambió esto?” → “¡Mi versión funciona!” (pero no sabes cuál es) ¿Por qué importa el control de versiones? 13 Con CVS: • Historial completo de cambios • Colaboración segura • Reversión instantánea • Lanzamientos confiables 💡 Hoy, no se trata de “usar Git”. Se trata de entender cómo el software moderno NO existiría sin él.
16. 📌 Ejemplo real (1995): Dos desarrolladores editan login.c. Uno hace push… el otro pierde su cambio. Nadie se daba cuenta hasta que el sistema falló en producción. 🔥 Lección clave: El control de versiones debe ser confiable… y no dejar espacio para errores humanos. 1980s–1990s — Los inicios: RCS y CVS 14 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
17. 📌 Contexto: En empresas de banca, telecomunicaciones, gobierno — SVN era el estándar. Porque todo estaba en un servidor seguro. Y nadie quería caos. ⚠ Problema emergente: Si el servidor se cae… ¡todo se pierde!. Si quieres contribuir a un proyecto open source… ¡tienes que pedir permiso! 🔥 Lección clave: Un sistema centralizado es seguro… pero frágil. Necesitamos descentralización. 2000s — La revolución: Subversion (SVN) 15
18. Linus lo creó porque CVS y SVN eran demasiado lentos para gestionar el kernel de Linux. Para ti, como Pythonista: • git init → empiezas • git add . → preparas cambios • git commit -m "fix: login bug" → guardas historia • git push origin main → compartes 2005–Presente — La explosión: Git 16 Git no es difícil. Es diferente. Pero una vez que entiendes el modelo de snapshot (no diffs), todo cambia. Lección clave: Git no es una herramienta de backup. Es una máquina del tiempo para tu código.
19. aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa El ecosistema moderno: GitHub, GitLab, Bitbucket 17 95% de los proyectos Python abiertos están en GitHub.Si no usas GitHub, estás fuera del ecosistema moderno. Recomendación práctica: Usa GitHub si estás en open source o trabajas con equipos modernos. Usa GitLab si tu empresa quiere control total (privacidad, compliance).
20. ✅ Esto es lo que usan Netflix, Spotify, Stripe… y tú deberías usarlo también. Evolución de flujos de trabajo — De “trunk-based” a “feature branching” 18
21. Herramientas complementarias que transforman el control de versiones 19
22. Conclusión: Git es el inglés del control de versiones. Las demás son dialectos locales. Aprende Git. Domínalo. Usa GitHub. Las demás las conocerás si el contexto lo exige. ¿Qué pasa con otras herramientas? Mercurial, Perforce, etc. 20
23. Regla de oro: “Si no puedes explicar qué cambió tu commit en una oración, no lo hagas.” Errores comunes que aún cometen los desarrolladores (y cómo evitarlos) 21
24. Predicción: Dentro de 5 años, los jóvenes ingenieros no entenderán cómo se hacía software antes de que la IA ayudara a escribir commits, revisar PRs y detectar riesgos automáticos. Pero el fundamento sigue siendo: Git. La IA solo lo mejora. No lo reemplaza. ¿Qué viene después de Git? 22
25. No importa qué tan bueno seas programando. Si no controlas tus versiones, no eres un ingeniero. Eres un artesano con suerte. Conclusión — Lo que debes llevar contigo 23
26. A programar !!! 24