el coste de no usar integración continua
Post on 28-Nov-2014
150 Views
Preview:
DESCRIPTION
TRANSCRIPT
C R I S T I A N R O M E R O M AT E S A N ZC O L E G I A D O 1 0 5 C O L E G I O I N G E N I E R O S I N F O R M ÁT I C O S
Integración continua: el coste de oportunidad
Punto de partida
1. Desarrollos de aplicaciones heterogéneos con estructuras diferentes.
2. Librerías usadas sin soporte actual y con bugs conocidos en productos subidos a producción.
3. Escasez de pruebas unitarias/ integración en desarrollos existentes.
4. Trazas de logs y gestión de excepciones poco clara entre capas.
5. Fases de desarrollo cortas, fases de mantenimiento grandes (por no decir infinitas).
6. Dificultad a la hora de acometer una refactorización.
7. Desarrollo nuevas funcionalidades generan errores en las ya existentes.
Problemática
Si has llegado a esta diapositiva, es que te preocupa el futuro de las aplicaciones dentro de tu entidad.
- La mala noticia son los graves problemas que hemos detectado.
- La buena noticia es que tenemos solución para los posibles dolores de cabeza que generaría los problemas expuestos anteriormente.
Bienvenido a la integración continua
Que es integración continua?
“The essence of my philosophy to software delivery is to build software so that it is always in a state where it could be put into production. We call this Continuous Delivery because we are continuously running a deployment pipeline that tests if this software is in a state to be delivered.”
Definición para toda la familia: la integración continua se basa en tener siempre subido código a nuestro repositorio que pueda ser puesto en producción, el proceso se encarga de ver si nuestro software cumple una seria de requisitos (pruebas, calidad etc..). Caso positivo Despliegue automático en entorno
Caso negativo Correos a los implicados para corregir los errores
Reingeniería de procesos desarrollo del software
1. En los 90 se desarrollaba software de manera atómica y desarrollos basados en clientes pesados.
2. En los años 2000 el auge web trae los desarrollos basados en clientes ligeros con servidores pesados
3. A finales de los años 2000 no solo interesa la web: Servicios Rest, móviles, web… Necesitamos piezas desacopladas y probadas. Ahora
tienen que ser muy reutilizables. Necesitamos un punto central donde se prueba y se
analice todo el código de nuestra entidad para garantizar a quien nos consume las reglas del juego y que todo funciona correctamente.
Necesitamos equipos de expertos concienciados en la necesidad de crear código de calidad.
Símil tecnológico
Madrid Barcelona
A favor En contra• Yo conozco mi coche.• Soy el mejor conduciendo
con este vehículo.• Esto funciona y no lo
cambio.• Sirve para ir de un sitio A
a otro sitio B como otros coches.
• Puedo llegar mas rápido a los sitios.
• Mas comodidad para conductor y acompañantes.
• Menor consumo.• Mayor seguridad en
transporte.• Menor siniestralidad
Símil real uso integración continua
Programación Sin CI Programación Con CI
• Yo conozco mi código• Soy el mejor programando con
mi metodología• Esto funciona y no lo cambio.• Hago lo mismo que el resto con
la “misma calidad”• Mi código es mi tesoro (aunque
el 90% sea copy paste )• He probado y funciona
“perfectamente”
• Todos conocen mi código (maven/gradle, pruebas, frameworks)
• Somos lo mejores desarrollando con una metodología real y tangible
• Menor consumo de “recursos”: equipos pequeños pero con mucha formación.
• Uso recursos en la nube, me centro en mi negocio y en lo que soy bueno.
• Todo se prueba para garantizar su funcionamiento y para facilitar refactorizaciones futuras
Consecuencias de desarrollos sin integración continua
1. No existe un sitio común donde se valide la herramienta. En local cada uno “certifica” que ha terminado y funciona correctamente
2. La realidad es otra: códigos con muchas líneas, con muchos if y poco claros debido a que nadie valida su calidad, solo el propio desarrollador.
3. No se conoce la versiones de las librerías que se usan, ni tan siquiera si estas funcionan correctamente.
4. En mi máquina esto me “funciona”. Se suba código a repositorios que no funciona y sin todas las dependencias: gasto de tiempo y dinero en algo que no aporta valor.
5. Tenemos desarrollos grandes donde cada cambio supone romper cosas que “funcionaban”. Mantenimiento infinito con gran coste.
6. Curva de aprendizaje enorme para nuevos desarrolladores: el conocimiento nunca reside en el código solo en la cabeza de los equipos
Argumentos en contra de su uso
1. Hacer pruebas y comprobar la integridad de nuestros proyectos consume tiempo en algo que no aporta funcionalidad a nuestro proyecto. Resultado: Gran coste de mantenimiento
2. Yo puedo programarlo todo, no me fio en el rendimiento de estas nuevas metodologías y herramientas (complejo del super-programador) Resultado: Reinventamos ruedas cada dia que nos ponemos delante de nuestro IDE favorito.
3. Esta metodología en otras entidades se puede usar pero mi empresa es diferente Resultado: Tiempos de desarrollo infinitos y poca calidad en código. Programemos entonces en ensamblador !!!!
4. No conozco estas nuevas herramientas y por lo tanto me será mas complicado avanzar Resultado: desarrollos repetitivos con programadores poco motivados.
Soy Jenkins vengo a poner orden
Os presento a nuestro nuevo amigo a partir de ahora:
JENKINS: Para servirles
Jenkins: y quien es el ???
1. Es la herramienta de integración continua de libre distribución mas usada en las empresas de todo el mundo. (Dell o Sony, proyectos de código abierto como GitHub y organizaciones varias como pueden ser Ebay, Facebook etc…)
2. Compila nuestro código y lanza un serie de tareas que nosotros le digamos: Lanzamiento de test unitarios y de integración Pruebas de carga Pruebas de integración con otros artefactos que me usan o uso para
ver que no rompe nada que ya estaba funcionando. Comprobación del numero de líneas que prueban nuestros test. Comprobaciones de calidad de código Envió de los posibles errores a las personas que lo han
realizado/responsables. Puesta automática de nuestros desarrollos en servidores/ entornos
de pruebas para tener siempre subido el ultimo código estable. TOMCAT, WAS, TESTFAIRY, TESTFLIGHT ETC….
3. A partir de ahora es un miembro mas del equipo y como tal debe de ser mimado por todos
Jenkins: Interfaz de usuario
Tareas a realizar con el código de la entidad.
Jenkins: Interfaz de usuario
Dependencias entre tareas
Jenkins: Interfaz de usuario
Cobertura de los test
Jenkins: Interfaz de usuario
Resultado de las ejecuciones
Jenkins: Interfaz de usuario
Resultado de las ejecuciones
Jenkins: Interfaz de usuario
Ejemplo subida automática a Testflight
Jenkins: Interfaz de usuario
Subida automática al servidor de desarrollo
Uso local/uso en la nube
Jenkins instalación versus Cloudbeed Jenkins puede ser usado como instalación local, como
servicio o bien corriendo en cualquier servidor de aplicaciones.
Existe una versión en la nube con todo lo necesario para tener entornos reales sin necesidad de mucho conocimiento.
Elegir uno u otro dependerá si queremos primar que nuestro código nunca salga de la entidad o bien queremos minimizar costes de manera enorme, donde solo tendremos que preocuparnos de usar, nunca de instalar.
top related