Una de las cosas más me gusta de las distribuciones basadas en Debian es la facilidad para instalar software utilizando apt-get.
Jenkins puede instalarse utilizando apt-get, pero antes de ejecutar apt-get install jenkins, uno debería actualizar la configuración de su repositorio de paquetes para así asegurarse de instalar la última versión. Esta página describe el proceso completo de instalación.
Enjoy it!
Hace dos semanas participé de este evento comunitario y me llevé un montón de cuestiones para profundizar y experimentar.
Una de las particularidades del evento fue la presencia de una importante cantidad de gente no relacionada al desarrollo de software, lo cual resultó muy enriquecedor.
Yo propuse dos sesiones: una para compartir experiencias de Aula Extendida y otra para debatir sobre los trabajos finales de las carreras de sistemas. Sólo la primera tuvo apoyo y se realizó, pero de todas formas hablé sobre el segundo tema en los pasillos, con algunos asistentes que estaban interesados. En la sesión de Aula Extendida, comenté mi experiencia en las materias que dicto en UBA y UNQ. Uno de los participantes planteó si es mejor utilizar las herramientas provistas por redes sociales que los sistemas típicos de los ambientes académicos (listas, foros, Moodle. etc).
Una de las sesiones que más me gustó fue la propuesta por la gente de EDEA, una organización que trabaja en cuestiones de diseño sustentable. Nos contaron sobre su organización, la forma en que trabajan e hicimos un par de dinámicas corporales muy interesantes.
También participé de una sesión facilitada por Alan Cyment, en la que compartió algunas técnicas «from the back» que suele utilizar en sus cursos.
Ya por la tarde participé de una sesión cuyo nombre no recuerdo, pero que trató sobre el impacto que tiene la tecnología en la educación. Bastante polémica e interesante. En cierto modo en la sesión de aula extendida hablamos principalmente sobre el efecto positivo, pero en este caso también tratamos algunos aspectos negativos y cómo lidiar con ellos.
En resumen, me resultó muy enriquecedor.
Los últimos días he estado ausente porque estuve trabajando en la preparación y el dictado de un workshop de Extreme Programming junto a mi colega @carlospeix.
Como era la primera vez que lo dictábamos, hicimos una invitación cerrada a algunos conocidos y ex-alumnos que gentilmente aceptaron ser nuestros «conejillos de indias».
El workshop salió un poco distinto a como lo habíamos planeado, pero a pesar de eso quedamos muy contentos con el resultado y los alumnos también se manifestaron positivamente.
Estimamos volver a dictarlo hacia mediados/fines de septiembre, pero de forma abierta al público.
Hace unos dias grabé unos videos explicativos de como instalar y configurar Jenkins para hacer integración y despliegue continuo.
Espero les resulten útiles.
Continuando con el tema pruebas, es hora de hablar de las pruebas no-unitarias.
Estas pruebas buscan probar componentes en forma NO aislada. Pero no son necesariamente pruebas de usuario. Hay ciertos casos donde es muy costoso aislar un componente para su prueba o que incluso, puede que no tengas sentido ese aislamiento pues la parte crítica radica justamente en la integración.
Son las pruebas que definirán si hemos completado o no una story dada. Son naturalmente pruebas de integración, ya que no prueban un componente aislado sino también la interacción de varios componentes (son no-unitarias).
Estas pruebas sí son de la incumbencia del usuario, por eso es que intentamos hacerlas con alguna herramienta que le resulte cómoda al usuario (que en general no es una persona técnica).
En nuestro caso usaremos Cucumber. Cuando hacemos BDD estamos haciendo este tipo de pruebas.
Nuestro foco con estas pruebas es asegurarnos que entendimos bien la story y que el código que escribimos hace lo que tiene que hacer. Como consecuencia de esto no debería ser relevante donde ejecuto las pruebas. O sea, no es necesario instalar la aplicación en un ambiente particular para ejecutar estas pruebas. Al mismo tiempo, podría en algunos casos escribir steps de cucumber que manipulen directamente los objetos de mi modelo.
Estas pruebas son similares a la anteriores, pero adicionalmente también queremos asegurarnos que la aplicación fue correctamente configurada y que todo su ecosistema está perfectamente funcional. Esto implica que sí es relevante el lugar donde pruebo la aplicación. Debería ser un ambiente similar al de producción.
Aquí ya no estamos hablando de hacer BDD. Respecto de las herramientas, puedo usar un robot tipo Selenium o VSTest o incluso Rspec. Es más, mucha gente hace estas pruebas en forma manual.
También puedo utilizar cucumber, pero con algunas restricciones:
Muchas veces estas pruebas se hacen en forma manual. El equipo termina el desarrollo, instala la app en un ambiente de test y un equipo de testers ejecutar pruebas a modo «caja» negra.
Continuará….
La cuestión se puso interesante. Por un lado algunos temas técnicos que sólo toco de oído (html5, responsive design, etc) y por otro algunas cuestiones de mercado y estrategia.
También publicaron algunas clases de invitados de la industria, muy interesante.
Continuará…
La cita es el próximo sábado 10 de Agosto en las instalaciones que tiene la UNTref en el Centro Cultural Borges (arriba de las Galerías Pacífico en la ciudad de Buenos Aires)
Es un evento totalmente gratuito que se realiza con formato Open Space, lo cual permite que todos seamos tanto oyentes como oradores ;-).
Para más información pueden ver aquí y aquí.
Si bien el evento es gratuito es requerida registración previa para estimar la cantidad de asistentes y así simplificar algunas cuestiones de logística, este el link para registrarse.
¡Nos vemos!
Si bien no hicimos cambios explícitos en la dinámica de la materia, incorporamos algunas cuestiones internas que generaron impacto muy positivo.
Una de estas cuestiones fue la incorporación del sistema de corrección de TPs. Esto nos ayudo a reducir muchísimo la carga de trabajo manual al mismo tiempo que le permitió a los alumnos tener un feedback inmediato de las entregas de sus trabajos.
Por otro lado, trabajamos con más foco en la coordinación interna de las clases de los distintos cursos de práctica, reutilizando materiales y ejemplos.
Finalmente, en lo que respecta al trabajo final, tuve dos grupos a mi cargo y ya desde la primer semanal tuvimos el soporte de un servidor de integración continua. Para esto, utilice el servicio que gentilmente nos brinda en forma gratuita CloudBees. Al mismo tiempo, fue muy positivo que ambos grupos tomaron en serio el build server, rompiendo el build muy pocas veces. Todo el proceso de build lo hicimos usando Ant y consistia en compilación, ejecución de pruebas (junit), medición de cobertura (cobertura) y verificación de código (checkstyle). Otro detalle que me pareció muy positivo es que gran parte del modelo de la aplicación lo hicieron usando TDD, lo cual derivó en un porcentaje de cobertura muy bueno (superior al 80%). Algunos otro docente, también usaron esta herramienta con muy buenos resultados y por ello en la retrospectiva decidimos extenderlo a toda la cátedra para el próximo cuatrimestre.
S bien ambas herramientas son build servers y en general uno utilizará alguno de los dos, en ciertos casos puede resultar muy útil utilizar ambos al mismo tiempo. Esto es hago que he hecho en mis últimos 3 proyectos.
Si bien, en varios sentidos Jenkins puede resultar mucho más «potente/flexible» que Travis, resulta que este último tiene una funcionalidad «matadora»: buildea todos lo branches existentes en el repositorio, sin requerir ninguna configuración adicional. Esto resulta especialmente útil cuando uno utiliza feature branches. Por su parte, Jenkins no tiene soporte actualmente para buildear varios branches en un mismo job. Claro que es posible jugar un poco con algunos plugins y lograr un workaround para lograrlo, pero no es algo out-of-the-box ni tampoco trivial.
Entonces, si para integración continua utilizo Travis, ¿para qué utilizo Jenkins? Simple, para automatizar mi proceso de despliegue y ejecutar algunas otras tareas que no puedo ejecutar con Travis como ser: enviar notificaciones via chat/sms, generar reportes, ejecutar tests de larga duración, etc.
Blog de NicoPaez 