Introducción
Introducción y Filosofia de DevOps
Containers y ambientes de desarrollo
Ambientes Homogéneos para Applicaciones
Implementación de Dockerfile
Ambientes Homogéneos para Infraestructura
Pruebas
Implementación de Pruebas
Sin pruebas no hay confianza
Integración Continua
Continuous Integration y Artifacts
Continuos integration y Continuos delivery
Implementación de CI con Jenkins
Implementación de Artifacts con Jenkins
Herramientas Externas en proceso de CI
Despliegue Continuo
CD a Ambiente Staging
Continous Deployments
Implementar acceptance tests en Jenkins
Completar Pipeline de CD
Reliability
Introducción a Incident Response
Introducción a Reliability - SLO/SLI
Implementar Uptime Monitoring
Exception Trackers y Logs
Métricas
Cierre del curso
Conclusiones
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
En este vídeo entramos en la teoría de Continuous Integration.
Con Git hacemos que nuestros cambios en el código queden en una historia que podamos probar antes de pasarlo a la rama master, saber que nuestros test estén pasando con éxito sin romper lo que tenemos en master.
Jenkins es nuestro automatizador de pruebas baja la última versión de nuestra rama donde se hizo un cambio y realiza las pruebas que tenemos y si fallan nos previene de romper nuestra rama principal y nos avisa cuáles fueron las pruebas que fallaron para corregirlo.
También podemos hacer un análisis de código, podemos tener algo muy complejo o un estilo que no gusta al equipo y se puede cambiar en esta parte del ciclo y mantenemos style guide bien y código limpio mientras desarrollamos.
Artifacts es nuestra unidad que va a pasar a todos los ambientes, debe ser algo inmutable. Es algo que podemos almacenar por cierta cantidad de tiempo, tal vez un año en caso en de que necesitemos hacer rollback.
Los integration tests son más productivos, tienen más alcance y tiene más valor.
Aportes 20
Preguntas 7
si bien el profe dice que es opinion de el, de que es mejor hacer integration tests. (tal vez eso es asi para ops)
la recomendación de google en cuanto a cuanto testear es la siguiente:
Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests.
fuente: https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
Con Continuous Integration, se desea probar cada uno de los cambios que reciba el código, cada Pull Request (en una rama diferente), pues si una rama no pasa las pruebas, no habría razón por la cual mezclarla a su rama destino, se puede dañar la versión en producción.
El ciclo comienza con Git, es muy importante que el código esté versionado, debe haber una historia de los cambios, esto es fundamental; y por consiguiente, el código debe estar hospedado en un repositorio remoto
Teniendo ya el código, debemos tener pruebas para ejecutar. Para este paso, se debe contar con un servidor de automatización (Jenkins, por ejemplo). Este servicio descargaría los últimos cambios del repositorio en la(s) rama(s) correspondiente(s), y ejecuta las pruebas unitarias. Si éstas pasan, se continúa con el ciclo; si no, lo rompe. De esta manera, se tiene la confianza de que el sitio en producción se mantendrá estable.
Hasta este punto, tenemos un historial de eventos: Si las pruebas de cierto commit pasaron, si el flujo continuó o se detuvo, sabemos quién realizó cada commit, etc.
Dentro de este mismo flujo, podemos implementar más soluciones aparte de las pruebas unitarias, como una integración con una herramienta de análisis de código.
El punto base con CI mantenemos estable el entorno de producción, mantenemos buenos styles guides y mantenemos código limpio.
La salida de todo CI es un artefacto.
El artefacto debe ser la unidad que va a ser desplegada en los ambientes, debe ser algo inmutable.
Es muy importante establecer un límite de aceptación en cuanto al porcentaje del Code Coverage, pero no confiarnos de ese porcentaje, y mantener activa la práctica de hacer Code Review, es algo que no puede ser confiado por las pruebas unitarias. Los Code Review son mucho más poderosos, porque: garantiza que nuestros compañeros sepan lo que está sucediendo en los nuevos features del servicio. Siempre debe haber un proceso de Pull Requests Review, y tiene mucho más valor que un Code Coverage.
para automatizar tu workflow yo recomendaria mas
GitHub Actions si usas GitHub o
GitLab CI/CD si usas GitLab
Jenkin es una buna opcion, ademas que puedes usarlo tanto si usas GitHub o GitLab
¿Cuáles herramientas recomiendan para hacer análisis de código en nodejs y en PHP?
¿Qué características tiene un init test y un integration test? ¿Cuál es la diferencia entre uno y otro?
Alguien me puede explicar qué es un artifact? No me quedó claro.
Continuous Integration.
Que es el Code Coverage?
es verdad que los integration test son mas descriptivos, pero sugeriria realizar mas unit test ya que los test de integracion son costosos en cuestion de procesamiento y para una aplcacion grande no queremos esperar 1 hora a que corran todos los test
Si soy el único programador, creo que es necesario aplicar integración continua, pero requiere de más esfuerzo y tiempo. Alguno de ustedes compañeros estan en mi posición y estan aplicando la integración continua para sus desarrollos?
Git: historia de cambios en el código.
Jenkins: automatizador de pruebas.
Artifacts: Sirve en caso de hacer rollback.
Entendido
Muy importante mantener sanidad 😂 (minuto 3:50)
Me parece muy importante que se cumpla cada uno de los procesos y sean cumplido en cada etapa una era de pruebas para así no contar con sorpresas en producción y si no pasa las pruebas es algo que el equipo de desarrollo debe tener en cuenta que no paso en ambiente de preproduccion
super claro 😃 gracias
La cobertura de código es una medida (porcentual) en las pruebas de software que mide el grado en que el código fuente de un programa ha sido comprobado. Sirve para determinar la calidad del test que se lleve a cabo y para determinar las partes críticas del código que no han sido comprobadas y las partes que ya lo fueron, además se puede utilizar como técnica de optimización dentro de un compilador optimizador para llevar a cabo una eliminación de código muerto, más específicamente sirve para detectar código inalcanzable. Fuente: (click).
Que herramientas recomiendan integrar con jenkins para almacenar artifacts jfrog por ejemplo?
Hasta el momento excelente el curso.
Por lo visto cuando se realiza pull request review se debe pasar por un proceso de aprobacion manual. Este caso no podriamos hacer Continuous Deployment. Que podemos hacer en este ultimo caso?
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
o inicia sesión.