Integración Continua


(Taby Mackenzie) #1

Estimad@s,
Con mi compañera Ana Pardo, estamos en proceso de implementar integración continua a nuestros proyectos de desarrollo, donde planteamos la siguiente metodología de pruebas:

Qué se hace en cada entorno
•Local: Se realizan pruebas Unitarias. Estas pruebas se diseñan y ejecutan a lo largo del desarrollo.
•Desarrollo: Se ejecutan las pruebas unitarias y de integración con cada push al repositorio.
•Pruebas: Se realiza un Smoke Test al momento en que se pasa el código desde Desarrollo a Pruebas. Se realizan además pruebas de UI, Regresión y Exploratorias de forma manual cada dos días (Tomando en cuenta que el Sprint dura dos semanas.)
•Producción: Se realiza el Smoke Test al desplegar código.
•Demo: Se realizan pruebas de Usabilidad y Aceptación, al finalizar el Sprint.

Nos gustaría saber su opinión o sí tienen experiencia en el tema, nos pudieran guiar o comentar la mejor forma de trabajo.

Además de cualquier material o información de como implementar integración continua.

Saludos y quedamos a la espera de su pronta respuesta

Gracias!


(felipetv) #2

que herramienta usan para hacer el build?


(Germán G.) #3

Todo lo que dices suena bien a alto nivel. A nivel de proceso. Los detalles son los que luego podrían presentar desafíos de implementación.

Alguien de la comunidad podría ofrecerse con un Meetup de Jenkins para integración contínua. Digo… :smiley:


(Taby Mackenzie) #4

Aún no hemos implementado una build, ya que estamos en la fase de diseño o los pasos previos


(felipetv) #5

partan por eso automatizar el proceso de build y tambien la estrategia para el repositorio.

puedes mandarme un mensaje para hablar con mas detalle.

podemos hacer alguna especie de coding dojo para implementar integracion continua


(Roberto Mejias) #6

Hola @TabyMackenzie,

Te dejo el link al blog de Nico Paez, él es un agilista de la comunidad Argentina muy crack en temas de técnicos:

http://blog.nicopaez.com/tag/integracion-continua/

Con respecto a mi experiencia, la integración continua debe ser paulatina, paso a paso. En mi trabajo, el primer paso fue sólo desplegar la aplicación en ambiente beta, para esto usamos Jenkins, esto considera la ejecución de PMD, test y Selenium. Adicionalmente a esto, ya estamos analizando la integración de herramientas para medir la cobertura de test, esto porque utilizamos TDD para desarrollar.

Otro tips que te puedo dar, es que la integración continua no debe centrar su foco sólo en las herramientas que utilizamos, si no que también y muy importante, en el cómo apoyamos al equipo para que saquen el máximo provecho a esta y sobre todo que sea un apoyo para el trabajo que realizan.

Saludos.


(Ana Pardo) #7

Muchas Gracias por sus comentarios.

Me queda una duda, una vez desplegado Jenkins con que frecuencia se ejecutan las pruebas? Cada vez que un desarrollador hace push al servidor realizan pruebas de integración? O qué políticas de pruebas están usando?

Estamos un poco al aire en cuanto a diseñar qué tipos de pruebas debe realizar la herramienta que decidamos usar y cada cuánto.


(felipetv) #8

puedes programar el jenkins para que ejecute las pruebas antes del deploy.

la mejor politica en mi opinion es usar TDD y las test de integracion deberian hacerse antes del despliegue en ambiente.


(felipetv) #9

en cuanto a que tipo de pruebas

herramientas tipo Junit y cucumber te puedan dar una idea.


(felipetv) #10

dejo el link de este libro con varias tecnicas que les pueden servir.


(Ana Pardo) #11

Muchas Gracias Felipe… Vamos a leer sobre el tema :slight_smile:


(Taby Mackenzie) #12

Muchas gracias Felipe, Saludos!! Cualquier cosa comentaremos como nos esta yendo por medio de este post.
Ojala se haga un meetup de Integración continua, saludos a tod@s !


(Germán G.) #13

Listo, tenemos meetup creado, por favor anotarse en el síguiente link.

La reunión va a ser en la Universidad Central, Escuela de Computación e Informática, Laboratorio de Computación N°3, quinto piso.

La universidad queda en Av. Santa Isabel 1186 (Entre San Diego y Nataniel Cox), Santiago Centro.


(Felipe Martin) #14

Hola!

Como comenta Felipe, una muy buena práctica es la de usar TDD (Test Driven Development) en conjunto con CI (Continuos Integration).

Sugiero un libro de “Uncle” Bob, o mejor aún sus videos “Clean Code”, donde hay un par de capítulos dedicados a esta práctica. De todos modos les dejo un link a un resumen.

Un elemento adicional importante, y que muchas veces no se menciona, es que el desarrollar utilizando TDD permite enfocarte en el diseño de tu solución, manteniendo una abstracción de cómo desarrollas. Es decir, al desarrollar el test primero te ves obligado a pensar en un nombre de clase, método y parámetros muy explícitos y de acuerdo al dominio en el que estás trabajando. De este modo evitas definir un nombre de método o parámetros a partir de la implementación, con lo que las interfaces son más claras y limpias manteniendo un buen nivel de encapsulamiento.


(David Lay) #15

@TabyMackenzie, @apardo yo estoy viendo dos cosas un poco distintas en lo que están intentando implementar. una es integración continua, y la otra deploy continuo. El primero se encarga del problema de realizar constantes pruebas sobre el código de todos los contribuyentes de una manera integrada (en vez de aislada en cada máquina). Esto termina con un un build verde o rojo en el servidor de integración continua. El segundo se encarga de de tomar el código integrado y publicarlo a un ambiente.

Yo lo tomaría por pasos, ya que cada etapa presenta distintos desafíos. Integración continua por ejemplo, el desafío inicial es lograr que el código compile en un comando por si solo (gestión de dependencias, scripts de compilación, generación de artefactos). Deploy automático o continuo, por otra parte, se debe encargar de la automatización de copiar y activar los distintos componentes (empaquetado, versionamiento, copiado seguro de archivos, migración de bases de datos, levantamiento de servicios, promoción de ambientes, etc)


(Guillermo Schwarz) #16

Idealmente se ejecutan todos los tests cada vez que compila.

Junit,selenium, cucumber, etc.

En la práctica, los tests de selenium y de cucumber pueden tomar varias horas para un proyecto muy grande, de modo que generalmente esos tests sólo se ejecutan en la noche en la misma máquina de integración continua.

Respecto de correr tests antes de instalar una versión en una máquina… No le veo el valor, pero lo hago de todas maneras, por si las moscas, si demora mucho lo desactivo, pero sólo si demora mucho, porque mientras más testeas algo, mejor.

Ahora bien, para mejorar la calidad del código lo que hago:

  1. Una máquina de integración con windows, otra con Linux.
  2. Una máquina de integración con jboss, otra con tomee.
  3. Una máquina de integración con MySQL, otra con Hsqldb.

Eso te da 8 máquinas. Porque más es mejor.

Además al tipear ant o mvn en la máquina de cada desarrollador, ejecuta los tests. Esto es muy importante, y el que no lo entienda debe ser sacrificado.

Hay gente que se preocupa de hacer todo rápido en vez de todo bien. Esa gente va en contra de la productividad, daña el proyecto y aunque la saques del proyecto, la marca del diablo queda en el proyecto en forma casi definitiva.

Ni siquiera reescribiendo su código con tests te va a librar de las malas vibras,no persinándose ni haciendo sacrificios a efestos, el Dios de la programación.

Por ejemplo te vas a encontrar con que en alguna parte ese tipo desactivo los tests, los comento o activo un switch que ignora las fallas en los tests. Y te vas a dar cuenta años después que el tipo es un saboteador, cuando el tipo este como jefe de proyecto de algún proyecto fracasado, porque odia programar y sólo aprende maneras de evadir responsabilidad y asignarle la culpa a otros por su incompetencia.

Antes de pasar a staging, testing o producción, es agradable ejecutar los tests. Supongamos que se te ocurre ejecutar los tests con jenkins en la máquina de producción, y parte de los tests envían mail pars avisar a los clientes que sus pedidos ya fueron despachados… No parece una buena idea…


(Guillermo Schwarz) #17

100% de acuerdo.

Lonque no entiendo es eso de la migración de ambientes. ?que significa?


(David Lay) #18

promoción de ambientes, es el workflow que te permite pasar de QA a prod, por ejemplo, ojalá con un solo click. Es solo un workflow, pero es parte importante asegurar que sea fácil y claro, tanto el proceso mismo como los criterios que se necesitan para la promoción o la denegación de promover una versión de pasar de una etapa a la otra


(Guillermo Schwarz) #19

Lo que yo hago:

  1. El producto pasa a staging todas las noches. Staging es lo más parecido posible a producción.
  2. En el jenkins de staging se ejecuta el branch staging. Es decir, cuando quiero pasar desarrollo a staging, simplemente agarro la rama de desarrollo y le hago merge con la rama de staging. Esto corre los scripts de update de BD y incluso subo un respaldo de producción a staging para estar seguro que está todo bien. Pruebas manuales de último minuto obviamente, porque “puede haber bugs en los tests”. Simplemente se ingresa el bug en el issue tracker, se resuelve ese issue mientras pruebo, y lo más simpático es que se crea un test automático para no tener regresiones.
  3. En producción hago lo mismo, pero usando la rama de producción. En vez de cargar un respaldo, se hacen 2 respaldos: antes de hacer upgrade de la BD y después de hacer upgrade de la BD. Ambos respaldos quedan para siempre guardados en un share con nombre, fecha, etc. Uno de esos respaldos se sube a staging en una etapa posterior del proceso que corre en la noche.

No tengo claro que significa eso de promoción si todo el proceso corre todas las noches, lo único que tengo que hacer es hacer merge con staging en la noche y si todo resulta bien, hago merge con producción (desde staging) al día siguiente. Ni siquiera me preocupo de llegar temprano al día siguiente… y a mi jefe casi se le cae el pelo… Si se cayera es porque el proceso está mal definido.

En contraste en JP Morgan:

  1. El JP mejicano llama a reunión “ya, pues acuérdensen de los cambios que hicieron por si se les olvidó subir algo”… yo pálido wn.
  2. Un equipo de gente ejecutando el paso a producción y el resto mirando. Todo fuera de las horas de trabajo normales. ejecución de scripts a mano. De hecho los problemas en producción se resuelven con SQL a mano, en caliente, sobre la BD de producción.

Qué porquería. Es lo único que puedo pensar.

Bueno y en resumen, eso de “promoción”, suena mal, a menos que se esté haciendo algo simple como el merge que describí. En hg es trivial, no sé en git, pero debiera ser similar.

En algunas empresas usan jenkins, pero los pasos a producción s ejecutan presioando un botón, o sea, no queda registro de nada. En otras se hace desde las máquinas de los desarrolladores porque son ágiles… creo que es verdad que son ágiles, pero sin la a.


(David Lay) #20

Es algo más tradicional, requiere de un repositorio de empaquetados con los binarios versionados, un servidor con el workflow (control) y agentes en cada ambiente (slaves) que ejecutan los scripts ante una notificación.

La gran diferencia es que entre dev->staging->prod no se compila nuevamente, sinó que se envían binarios de uno a otro ambiente. Implica varios detalles menores, como asegurar que la optimización de binarios está activa en dev y que se generan simbolos (para debug) pero que no se envían a producción y cosas bellas de ese estilo.