A√ļn no tienes acceso a esta clase

Crea una cuenta y contin√ļa viendo este curso

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 18

Preguntas 6

Ordenar por:

¬ŅQuieres ver m√°s aportes, preguntas y respuestas de la comunidad? Crea una cuenta 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?

Alguien me puede explicar qué es un artifact? No me quedó claro.

¬ŅQu√© caracter√≠sticas tiene un init test y un integration test? ¬ŅCu√°l es la diferencia entre uno y otro?

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?

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?

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?