Integración Continua

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Integración Continua

Guillermo Sapaya-2
Hola,
¿alguno ha experimentado llevar adelante proyectos con integración continua?
En tal caso, ¿podrían compartir sus experiencias?
Algunas preguntas que me interesan:
- ¿Qué usan como repositorio de código?
- En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
- ¿Tiene un impacto muy alto al comienzo?

Saludos,

Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

Angel Java Lopez
Hola gente!

Guillermo, ni idea de esto en Smalltalk ... ;-)... pero si puedo aportar dos videos, discusiones:

http://www.altnethispano.org/wiki/van-2009-12-18-automatizacion.ashx
Donde se expone que hace un build continuo puede ser algo relativamente facil de hacer al comienzo ("la cuarta vez que hago algo, automatizarlo"). He visto entonces equipos agiles (iteraciones 1 semana, Scrum) que ya en los primeros dias levantan una maquina virtual de integracion continua.

Luego:
http://www.altnethispano.org/wiki/van-2010-10-26-integracion-continua.ashx
mas sobre el tema de integracion continua

Con respecto a los tests, depende del proyecto. Yo he participado de proyectos con TDD, entonces ahi no me importo tanto que sean unit test, sino que fuera todo desarrollado con TDD. El code coverage alto no es entonces un objetivo, sino que practicamente es un resultado derivado de aplicar bien TDD.
Tambien he participado de proyectos SIN TDD, pero con testing agregado en el medio. No seria el mejor camino, pero bue ;-). En esos casos, se trato de llegar a un code coverage de 80% o mas.

He tenido proyectos con integracion continua con Cruise Control, y con Team City (el actual). En cuanto alguien hace un commit que da tests en rojo... ;-)... compra facturas para la tarde ;-)

He visto proyectos (tres equipos, en tres paises distintos), con un build continuo sin errores por 6 meses, si mal no recuerdo. No tengo el enlace. Preguntar en Twitter a @kzu.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez


2011/8/4 Guillermo Sapaya <[hidden email]>
Hola,
¿alguno ha experimentado llevar adelante proyectos con integración continua?
En tal caso, ¿podrían compartir sus experiencias?
Algunas preguntas que me interesan:
- ¿Qué usan como repositorio de código?
- En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
- ¿Tiene un impacto muy alto al comienzo?

Saludos,

Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

Guillermo Schwarz
Guillermo,

En Java lo que nos ha funcionado mejor es LuntBuild (gratuito y open source). Agarra el còdigo desde SVN y ejecuta el build.xml con ant, con lo que puedes hacer que compile, corra los tests unitarios de JUnit y los tests de integraciòn, o de aceptaciòn, hechos con Selenium. Además cuando algún test no te pasa y estás a punto de entregar pero sabes que es muy difìcil que te pillen el bug, puedes comentarlo colocando __ delante del test, de modo que las pruebas no se ejecuten, pero que puedas hacer refactoring sin que el IDE deje de refactorizar el còdigo comentado.

En Smalltalk sè que existe SUnit y tengo entendido que SqueakSource es open source, lo que permitirìa reemplazar el SVN, pero nunca lo he podido hacer funcionar bien. Además no sé si existe un servidor de build equivalente a LuntBuild. Debe haberlo, pero no sabría dónde buscarlo. Selenium debería funcionar igual independiente de la tecnología con la que desarrolles tu sistema.

Saludos,
El otro Guillermo.

2011/8/4 Angel Java Lopez <[hidden email]>
Hola gente!

Guillermo, ni idea de esto en Smalltalk ... ;-)... pero si puedo aportar dos videos, discusiones:

http://www.altnethispano.org/wiki/van-2009-12-18-automatizacion.ashx
Donde se expone que hace un build continuo puede ser algo relativamente facil de hacer al comienzo ("la cuarta vez que hago algo, automatizarlo"). He visto entonces equipos agiles (iteraciones 1 semana, Scrum) que ya en los primeros dias levantan una maquina virtual de integracion continua.

Luego:
http://www.altnethispano.org/wiki/van-2010-10-26-integracion-continua.ashx
mas sobre el tema de integracion continua

Con respecto a los tests, depende del proyecto. Yo he participado de proyectos con TDD, entonces ahi no me importo tanto que sean unit test, sino que fuera todo desarrollado con TDD. El code coverage alto no es entonces un objetivo, sino que practicamente es un resultado derivado de aplicar bien TDD.
Tambien he participado de proyectos SIN TDD, pero con testing agregado en el medio. No seria el mejor camino, pero bue ;-). En esos casos, se trato de llegar a un code coverage de 80% o mas.

He tenido proyectos con integracion continua con Cruise Control, y con Team City (el actual). En cuanto alguien hace un commit que da tests en rojo... ;-)... compra facturas para la tarde ;-)

He visto proyectos (tres equipos, en tres paises distintos), con un build continuo sin errores por 6 meses, si mal no recuerdo. No tengo el enlace. Preguntar en Twitter a @kzu.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez



2011/8/4 Guillermo Sapaya <[hidden email]>
Hola,
¿alguno ha experimentado llevar adelante proyectos con integración continua?
En tal caso, ¿podrían compartir sus experiencias?
Algunas preguntas que me interesan:
- ¿Qué usan como repositorio de código?
- En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
- ¿Tiene un impacto muy alto al comienzo?

Saludos,

Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

Hernan Wilkinson-3
In reply to this post by Guillermo Sapaya-2
En Mercap están haciendo IC con Jenkins
Tambien los builds de pharo lo hacen así... fijate que hay algo escrito al respecto

2011/8/4 Guillermo Sapaya <[hidden email]>
Hola,
¿alguno ha experimentado llevar adelante proyectos con integración continua?
En tal caso, ¿podrían compartir sus experiencias?
Algunas preguntas que me interesan:
- ¿Qué usan como repositorio de código?
- En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
- ¿Tiene un impacto muy alto al comienzo?

Saludos,

Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com
Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

German Morales-3
In reply to this post by Angel Java Lopez
Trabajé en proyectos con esa modalidad de "castigo", pero tuvimos que suspender porque quedamos reventados de tantas facturas!
Eso demuestra que algunas metodologías son buenas... pero con la gente correcta. :-X

2011/8/4 Angel Java Lopez <[hidden email]>
He tenido proyectos con integracion continua con Cruise Control, y con Team City (el actual). En cuanto alguien hace un commit que da tests en rojo... ;-)... compra facturas para la tarde ;-)

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

German Morales-3
In reply to this post by Guillermo Sapaya-2
Guillermo,

ahora contestando más lo original:

¿alguno ha experimentado llevar adelante proyectos con integración continua?
Si, pero no en Smalltalk.
 
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
En nuestro caso tenemos codigo "compartido" con gente que no es muy amante de escribir tests.
Si las cosas están bien separadas (ej: differentes modulos, capas, etc), lo que te importa es que lo que vos estés tocando tenga buenos tests. El resto, y bueno...
 
- ¿Tiene un impacto muy alto al comienzo?
El proyecto tiene que estar preparado para soportar build/test en forma automática.


Saludos,


--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

gcotelli
In reply to this post by Guillermo Sapaya-2
Guillermo,
En Mercap nosotros venimos usando el Jenkins para varias de las tareas de Integración Continua (aunque no para el merge, este paso lo hacemos con una herramienta de merge propia pero que requiere asistencia humana en caso de conflictos que no puedan resolverse automáticamente). De todos modos tratamos de integrar seguido, no te digo todos los días pero cada 3 o 4 días seguro sale una versión nueva.

Para lo que si estamos usando el Jenkins es:
- Cargar la línea base del producto desde una imagen mínima con cada versión que se cierra
- Correr la suite de tests unitarios, el SmallLint, el Coverage, estándares de codificación, etc.
- Generar la imágenes empaquetadas para Runtime para las distintas plataformas
- Correr las suites de tests de productos de terceros que usamos
- Generar instalaciones prototípicas
- Correr tests que interfaceen con distintos backends externos (Bases de datos, etc.)
- Archivar los artefactos que nos interesan de estas tareas

Hay un par de cosas más que también podríamos automatizar pero no tuvimos tiempo todavia :)

El Jenkins en gral. esta bueno, aunque muchas de las opciones no nos aplican mucho a nosotros y la mayoría de los plugins son orientados a tener archivos y no repositorios de código como tenemos en Smalltalk (nosotros usamos ENVY). Para los proyectos que tenemos corriendo ahi casi todos los pasos son del tipo "Ejecución de línea de comandos" y corremos la imagen Smalltalk con algún script Smalltalk como parámetro  que hace lo que necesitamos (cargar configuration maps, correr tests, hacer el package, etc.)

Lo que te puedo decir es que para todo lo que ahora estén haciendo a mano y es super repetitivo vayan de a poco tratando de meterlo en alguna herramienta de automatización. Nosotros fuimos haciéndolo de a poco y no es tan traumático, sobre todo por el tiempo que te ahorras después si tuvieras que hacer todo eso a mano.

Sobre lo de arrancar con un índice bajo de unit tests no te podría decir porque en este producto se hizo TDD desde un principio con lo que siempre tuvimos una buena batería de tests para probar.

Saludos
Gabriel

2011/8/4 Guillermo Sapaya <[hidden email]>
Hola,
¿alguno ha experimentado llevar adelante proyectos con integración continua?
En tal caso, ¿podrían compartir sus experiencias?
Algunas preguntas que me interesan:
- ¿Qué usan como repositorio de código?
- En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
- ¿Tiene un impacto muy alto al comienzo?

Saludos,

Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

Guillermo Schwarz
In reply to this post by Guillermo Schwarz
Guillermo,

Se me olvidaba comentar. Respecto de la experiencia (si fue buena o mala) depende mucho del proyecto. En general te dirìa que 90% buena y 10% regular. Nunca me ha pasado que deba sacar la màquina de build porque siempre el proyecto sale màs ràpido cuando hay una màquina de build.

Lo que dice Martin Fowler es que debes configurar la màquina de build antes de partir el proyecto, lo cual he comprobado que es 100% verdad. Te demoras un poco al principio, pero te ahorras dìas luego durante el proyecto.

Si el proyecto es chico, la compilaciòn despuès de cada checkìn demora un par de minutos y te dice si algo no compila o si se cae un test, es genial. En un proyecto con 4 o 5 personas y unos 6 meses funciona muy bien y nunca pasa de los 5 minutos de compilaciòn.

Si el proyecto es gigante, digamos 15 personas y 1.5 años de desarrollo, la integraciòn continua es necesaria, pero puede llegar a demorar unas 3 horas en compilar y pasar los tests. Hay que tener una serie de màquinas de build idealmente. Por lo menos una para despuès de cada check-in,  una para funcionar como Staging, que ejecute 2 veces al dìa (digamos a la hora de almuerzo y en la noche) de modo que despuès de almuerzo o al dìa siguiente verifiques que lo que hiciste sigue funcionando. ¿Porquè? Porque una cosa es que pase el test y otra que efectivamente funcione. Suena ridìculo, pero a veces falla de maneras inesperadas, tienes que agregar tests, etc.

Además debieras tener una màquina de test en la que los testers puedan compilar cuando quieran porque a veces se demoran muchos dìas en hacer una prueba. Segùn los XPers no es necesario tener testers, pero en mi experiencia las especificaciones estàn màs completas al final que al principio, de modo que especialmente si el proyecto es muy grande, de todas maneras se requiere testers para probar cosas raras como ciclos de negocio que involucran decenas de casos de uso y que no habìas pensado al principio del proyecto (hay que considerar que proyectos asì tienen muchos controles de cambio).

Saludos,
Guillermo.

2011/8/4 Guillermo Schwarz <[hidden email]>
Guillermo,

En Java lo que nos ha funcionado mejor es LuntBuild (gratuito y open source). Agarra el còdigo desde SVN y ejecuta el build.xml con ant, con lo que puedes hacer que compile, corra los tests unitarios de JUnit y los tests de integraciòn, o de aceptaciòn, hechos con Selenium. Además cuando algún test no te pasa y estás a punto de entregar pero sabes que es muy difìcil que te pillen el bug, puedes comentarlo colocando __ delante del test, de modo que las pruebas no se ejecuten, pero que puedas hacer refactoring sin que el IDE deje de refactorizar el còdigo comentado.

En Smalltalk sè que existe SUnit y tengo entendido que SqueakSource es open source, lo que permitirìa reemplazar el SVN, pero nunca lo he podido hacer funcionar bien. Además no sé si existe un servidor de build equivalente a LuntBuild. Debe haberlo, pero no sabría dónde buscarlo. Selenium debería funcionar igual independiente de la tecnología con la que desarrolles tu sistema.

Saludos,
El otro Guillermo.


2011/8/4 Angel Java Lopez <[hidden email]>
Hola gente!

Guillermo, ni idea de esto en Smalltalk ... ;-)... pero si puedo aportar dos videos, discusiones:

http://www.altnethispano.org/wiki/van-2009-12-18-automatizacion.ashx
Donde se expone que hace un build continuo puede ser algo relativamente facil de hacer al comienzo ("la cuarta vez que hago algo, automatizarlo"). He visto entonces equipos agiles (iteraciones 1 semana, Scrum) que ya en los primeros dias levantan una maquina virtual de integracion continua.

Luego:
http://www.altnethispano.org/wiki/van-2010-10-26-integracion-continua.ashx
mas sobre el tema de integracion continua

Con respecto a los tests, depende del proyecto. Yo he participado de proyectos con TDD, entonces ahi no me importo tanto que sean unit test, sino que fuera todo desarrollado con TDD. El code coverage alto no es entonces un objetivo, sino que practicamente es un resultado derivado de aplicar bien TDD.
Tambien he participado de proyectos SIN TDD, pero con testing agregado en el medio. No seria el mejor camino, pero bue ;-). En esos casos, se trato de llegar a un code coverage de 80% o mas.

He tenido proyectos con integracion continua con Cruise Control, y con Team City (el actual). En cuanto alguien hace un commit que da tests en rojo... ;-)... compra facturas para la tarde ;-)

He visto proyectos (tres equipos, en tres paises distintos), con un build continuo sin errores por 6 meses, si mal no recuerdo. No tengo el enlace. Preguntar en Twitter a @kzu.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez



2011/8/4 Guillermo Sapaya <[hidden email]>
Hola,
¿alguno ha experimentado llevar adelante proyectos con integración continua?
En tal caso, ¿podrían compartir sus experiencias?
Algunas preguntas que me interesan:
- ¿Qué usan como repositorio de código?
- En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
- ¿Tiene un impacto muy alto al comienzo?

Saludos,

Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

dcoronel32@gmail.com
In reply to this post by Guillermo Sapaya-2
Hola Guiye.
Yo guardo muchos "fuentes" en la base de datos que se compilan
mientras el sistema anda, tengo una serie de objetos para eso y podés
hacer cosas como meter un paquete Dolphin, o un método o lo que te
parezca. Tienen una firma por seguridad y basicamente voy subiendo
partes en las distintas instalaciones. No es gran cosa, es muy chico y
podría estar mejor, pero me salvó la vida un millón de veces. En los
lugares que veo que acumulo muchos paquetes, es un indicador de que ya
estamos para hacer una nueva versión. Está bueno porque uno ve la
historia de un cliente, se hace fácil mover soluciones entre clientes,
personalizar cosas y principalmente guardar y reusar esas
personalizaciones o patchs.

Diego Coronel

On Aug 4, 2:39 pm, "Guillermo Sapaya" <[hidden email]> wrote:

> Hola,
> ¿alguno ha experimentado llevar adelante proyectos con integración continua?
> En tal caso, ¿podrían compartir sus experiencias?
> Algunas preguntas que me interesan:
> - ¿Qué usan como repositorio de código?
> - En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
> - ¿Qué porcentaje de code coverage poseen con sus tests?
> - ¿Se puede arrancar con un bajo índice de UnitTests?
> - ¿Tiene un impacto muy alto al comienzo?
>
> Saludos,
>
> Guillermo Sapaya
> Gerente de Desarrollo
> InfOil S.A. -www.infoil.com.ar
> Tronador 2244, C1430DKP
> Buenos Aires, Argentina
> TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

Guillermo Sapaya-2
In reply to this post by gcotelli
Hola,
muchas gracias a todos por compartir sus experiencias y consejos! Seguí cada una de sus respuestas con atención.
Creo que vamos a apuntar a algo muy parecido a lo que me contaba Gabriel que hacen en Mercap. Estoy leyendo bastante de Martin Fowler y sobre servidores de IC (Jenkins en particular). Espero llegar a buen puerto!

Saludos y gracias!


Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

From: Gabriel Cotelli [mailto:[hidden email]]
To: [hidden email]
Sent: Thu, 04 Aug 2011 16:57:10 -0300
Subject: Re: [clubSmalltalk] Integración Continua

Guillermo,
En Mercap nosotros venimos usando el Jenkins para varias de las tareas de Integración Continua (aunque no para el merge, este paso lo hacemos con una herramienta de merge propia pero que requiere asistencia humana en caso de conflictos que no puedan resolverse automáticamente). De todos modos tratamos de integrar seguido, no te digo todos los días pero cada 3 o 4 días seguro sale una versión nueva.

Para lo que si estamos usando el Jenkins es:
- Cargar la línea base del producto desde una imagen mínima con cada versión que se cierra
- Correr la suite de tests unitarios, el SmallLint, el Coverage, estándares de codificación, etc.
- Generar la imágenes empaquetadas para Runtime para las distintas plataformas
- Correr las suites de tests de productos de terceros que usamos
- Generar instalaciones prototípicas
- Correr tests que interfaceen con distintos backends externos (Bases de datos, etc.)
- Archivar los artefactos que nos interesan de estas tareas

Hay un par de cosas más que también podríamos automatizar pero no tuvimos tiempo todavia :)

El Jenkins en gral. esta bueno, aunque muchas de las opciones no nos aplican mucho a nosotros y la mayoría de los plugins son orientados a tener archivos y no repositorios de código como tenemos en Smalltalk (nosotros usamos ENVY). Para los proyectos que tenemos corriendo ahi casi todos los pasos son del tipo "Ejecución de línea de comandos" y corremos la imagen Smalltalk con algún script Smalltalk como parámetro  que hace lo que necesitamos (cargar configuration maps, correr tests, hacer el package, etc.)

Lo que te puedo decir es que para todo lo que ahora estén haciendo a mano y es super repetitivo vayan de a poco tratando de meterlo en alguna herramienta de automatización. Nosotros fuimos haciéndolo de a poco y no es tan traumático, sobre todo por el tiempo que te ahorras después si tuvieras que hacer todo eso a mano.

Sobre lo de arrancar con un índice bajo de unit tests no te podría decir porque en este producto se hizo TDD desde un principio con lo que siempre tuvimos una buena batería de tests para probar.

Saludos
Gabriel

2011/8/4 Guillermo Sapaya <[hidden email]>
Hola,
¿alguno ha experimentado llevar adelante proyectos con integración continua?
En tal caso, ¿podrían compartir sus experiencias?
Algunas preguntas que me interesan:
- ¿Qué usan como repositorio de código?
- En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
- ¿Tiene un impacto muy alto al comienzo?

Saludos,

Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Integración Continua

Mariano Martinez Peck


2011/8/5 Guillermo Sapaya <[hidden email]>
Hola,
muchas gracias a todos por compartir sus experiencias y consejos! Seguí cada una de sus respuestas con atención.
Creo que vamos a apuntar a algo muy parecido a lo que me contaba Gabriel que hacen en Mercap. Estoy leyendo bastante de Martin Fowler y sobre servidores de IC (Jenkins en particular). Espero llegar a buen puerto!


Mirá los scripts que se usan en  Pharo. Hay muchas cosas hechas que podes reutilizar:

https://github.com/renggli/builder

http://www.squeaksource.com/HudsonBuild.html

http://gitorious.org/pharo-build/
 
Saludos y gracias!



Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

From: Gabriel Cotelli [mailto:[hidden email]]
To: [hidden email]
Sent: Thu, 04 Aug 2011 16:57:10 -0300
Subject: Re: [clubSmalltalk] Integración Continua


Guillermo,
En Mercap nosotros venimos usando el Jenkins para varias de las tareas de Integración Continua (aunque no para el merge, este paso lo hacemos con una herramienta de merge propia pero que requiere asistencia humana en caso de conflictos que no puedan resolverse automáticamente). De todos modos tratamos de integrar seguido, no te digo todos los días pero cada 3 o 4 días seguro sale una versión nueva.

Para lo que si estamos usando el Jenkins es:
- Cargar la línea base del producto desde una imagen mínima con cada versión que se cierra
- Correr la suite de tests unitarios, el SmallLint, el Coverage, estándares de codificación, etc.
- Generar la imágenes empaquetadas para Runtime para las distintas plataformas
- Correr las suites de tests de productos de terceros que usamos
- Generar instalaciones prototípicas
- Correr tests que interfaceen con distintos backends externos (Bases de datos, etc.)
- Archivar los artefactos que nos interesan de estas tareas

Hay un par de cosas más que también podríamos automatizar pero no tuvimos tiempo todavia :)

El Jenkins en gral. esta bueno, aunque muchas de las opciones no nos aplican mucho a nosotros y la mayoría de los plugins son orientados a tener archivos y no repositorios de código como tenemos en Smalltalk (nosotros usamos ENVY). Para los proyectos que tenemos corriendo ahi casi todos los pasos son del tipo "Ejecución de línea de comandos" y corremos la imagen Smalltalk con algún script Smalltalk como parámetro  que hace lo que necesitamos (cargar configuration maps, correr tests, hacer el package, etc.)

Lo que te puedo decir es que para todo lo que ahora estén haciendo a mano y es super repetitivo vayan de a poco tratando de meterlo en alguna herramienta de automatización. Nosotros fuimos haciéndolo de a poco y no es tan traumático, sobre todo por el tiempo que te ahorras después si tuvieras que hacer todo eso a mano.

Sobre lo de arrancar con un índice bajo de unit tests no te podría decir porque en este producto se hizo TDD desde un principio con lo que siempre tuvimos una buena batería de tests para probar.

Saludos
Gabriel

2011/8/4 Guillermo Sapaya <[hidden email]>
Hola,
¿alguno ha experimentado llevar adelante proyectos con integración continua?
En tal caso, ¿podrían compartir sus experiencias?
Algunas preguntas que me interesan:
- ¿Qué usan como repositorio de código?
- En caso de no usar las herramientas mas conocidas del mercado (Subversion, Hudson, Maven, etc.) ¿Se hicieron las suyas propias con buenos resultados?
- ¿Qué porcentaje de code coverage poseen con sus tests?
- ¿Se puede arrancar con un bajo índice de UnitTests?
- ¿Tiene un impacto muy alto al comienzo?

Saludos,

Guillermo Sapaya
Gerente de Desarrollo
InfOil S.A. - www.infoil.com.ar
Tronador 2244, C1430DKP
Buenos Aires, Argentina
TEL (5411)4542-9999 int. 122

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org



--
Mariano
http://marianopeck.wordpress.com

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org