No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Continuous Integration y Artifacts

7/21
Recursos

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

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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.

  • C贸digo versionado: GIT GITHUB
  • Unit Test/ Integrations Test Servidor de automatizaci贸n (Jenkins en infraestructura propia)
  • An谩lisis de c贸digo
  • Test Coverage:

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.

Excelente contenido. 100 puntos.

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?