Bootcamp2012dsv code management continuois integration

Asuntos Internos

El código fuente:
“Somos lo que vendemos”

dsv@nextret.net
Paseo Bonanova, 9 - 08022 Barcelona - T. 932 541 530
Gestión código fuente www.nextret.net - info@nextret.net
Fortuny, 3 - 28010 Madrid - T. 917 021 645

1. DOS HISTORIAS
DE MUCHO MIEDO
Gestión código fuente 2

1. Dos historias de mucho miedo

Estas son dos historias que pasaron de verdad (o no).



Alberto Benitez Cazorla (abc@nextret.net) dejó la
empresa para ir a criar marmotas en el Pirineo.

 Sus compañeros de proyecto no encontraron el código
fuente de su aplicación el día que había que hacer una
corrección urgente para ya de antes de ayer.

 Cuando por fin lo encontraron, nunca supieron cual de los
tres proyectos modificados en fechas similares era el
bueno.



Xavier Yuste Zamora (xyz@nextret.net) estuvo una
temporada en un cliente y le pidieron venir a la
central para modificar un proyecto anterior.

 Al volver, su PC había sido formateado y donado a una
ONG que lo usa para las altas y bajas de una leprosería.

 El código fuente había desaparecido.


2. ¡TENEMOS UNA ISO-LUCION!
O NO.

2. ¡Tenemos una ISO-lución! O no.

La ISO-9001 dice que la copia de backup del fuente debe estar en
i:_exeExxxxxFuentes:
“¿Mentiendes?”

 net use i: ntnx01home$

 No C:miproyectobackup2034-13-31-laCaixaExtranet.rar

 No i:_exeExxxxxDocsJava2034-13-31-laCaixaExtranet.rar

 No j:TransferTeLoDejoAqui2034-13-31-laCaixaExtranet.rar



La ISO-9001 de la empresa dice que el fuente debe estar en
Problemas

 Nadie lo copia.

 Si se acuerdan de copiarlo, se hace manualmente.

 Manual == ERRORES



La ISO-9000 de la empresa dice que el fuente debe estar en
Dudas
 ¿Como se relaciona con la copia local del desarrollador?
 ¿DONDE ESTÁ LA COPIA LOCAL?
 ¿Como estamos seguros que todo lo copiado es lo que debe estar?
 ¿Está todo lo que debe ser copiado?
 ¿Todo lo copiado debe estar ahí?
 ¿Gromenauer?


3. “UNA NUEVA ESPERANZA”

3. “Una nueva esperanza”
“Usa el control de código, Luke”

A. Da igual cual... ¡sólo usa alguno!

 Subversion, git, hg, CVS
 Visual Source Safe, aceptamos pulpo como SCM?
 Google is your friend.
 Busca, encuentra, lee, aprende... usa.

B. Usalo ordenadamente

 Organiza y automatiza tu proyecto.
 Usa servidores confiables, propios o del cliente.
 Cumple con los 10 mandamientos.
 Cumple las best practices de tu gestor de código.



Dale alegría a tu proyecto

La alegría de:

 Que tú y todos sepan donde está cada cosa.

 Que todo esté controlado y no falte nada.

 Que se pueda hundir el mundo y puedas seguir.



Dale alegría a tu proyecto

Y todo en unos sencillos pasos...


4. ORGANIZA. AUTOMATIZA.

4. Organiza. Automatiza.

C:_exeExxxxx == I:_exeExxxxx
 Y punto.



X:_exeExxxxxFuentesSVN
 X in { I, C }
 Checkout del código fuente del proyecto.
 Bajo control de versiones siempre.
 SVN o nombre descriptivo. Ejemplo:
 En local C: puede trabajarse en el trunk o en un branch.
 En directorio de proyecto I: todo el árbol.



C:_exeExxxxxworkspace
 Para agrupar proyectos relacionados y aislarlos de los que no lo son.
 C:_exeExxxxxeclipse: IDE con todos los plugins del proyecto.



SlikSVN
 Cliente Subversion de linea de comandos para Windows.
 http://www.sliksvn.com/en/download



¡Y ya está!
 Así de fácil.


5. LOS 10 MANDAMIENTOS DEL
CONTROL DE CÓDIGO

5. Los 10 mandamientos del control de código.
▊ · · · · · · · · · 10%

A. Deja de usar VSS. Ya.
 Está muerto. Como el pulpo Paul.
 http://support.microsoft.com/lifecycle/search/default.aspx?alpha=Visual+SourceSafe


▊▊ · · · · · · · · 20%

A. Si no está en control de código no existe.
 Repetir cada día este mantra:
 “La única medida de progreso es código operativo bajo control, ommm”

 Copias locales:
 Riesgo y descontrol.

 Código controlado:
 Buenas prácticas.


▊▊▊ · · · · · · · 30%

A. ¡Commit pronto, commit regular… y sin remolonear!

 Cada revisión con commit es un punto de recuperación.
 Para esas “pequeñas pérdidas” de que las cosas funcionen.

 El riesgo de pesadillas de merge crece con el tiempo.
 Entropía del proyecto =
número de desarrolladores x tiempo sin hacer merge.

 Enfuerza el aislamiento de funcionalidades en unidades de trabajo.
 Un commit, una cosa que funciona, una parte del todo.


▊▊▊▊ · · · · · · 40%

A. Inspecciona los cambios antes de subirlos.
 No subir basura.


▊▊▊▊ · · · · · · 40%

 Subir cambios reales que afecten a todo el mundo.


▊▊▊▊ · · · · · · 40%

 Revisa los ficheros uno por uno y valida los cambios.


▊▊▊▊▊ · · · · · 50%

A. Comenta el commit como si te fuese la vida en ello.
 En dos semanas ni tu mismo vas a saber qué cambiaste.
 Imagina que el equipo de soporte de tu código está formado por
maníacos homicidas con un hacha que saben dónde vives.


▊▊▊▊▊ · · · · · 50%

A. Comenta el commit como si te fuse la vida en ello.
 Buenos comentarios de commit te salvarán el culo en un blame.


▊▊▊▊▊ · · · · · 50%

A. Comenta el commit como si te fuse la vida en ello.
 Los comentarios de commit son la crónica de tu proyecto.


▊▊▊▊▊ · · · · · 50%

A. Comenta el commit como si te fuese la vida en ello.
 Antipatrones de comentario:
 Algunas mierdecillas...
 Funciona!
 Arreglados algunos jodidos errores
 fix
 Arreglo de un pequeño bug...
 Actualizado
 typo
 Revision 1024!!
 http://stackoverflow.hewgill.com/questions/909/338.html
 ( /)
(O.o)
(> <) El conejito aprueba los cambios.


▊▊▊▊▊▊ · · · · 60%

A. Sólo tu harás commit de tus cambios
 Antipatrón: Desarrollador jefe que revisa los cambios ajenos y hace commit.
 Eso no es control de código.
 Eso es una guardería.


▊▊▊▊▊▊▊ · · · 70%
A. Versionar la base de datos no es opcional.
 Apaliza al DBA hasta que lo entienda.

 Dos estrategias:
 Versionar un script de creación desde el cero inicial.
 “Y se hizo el esquema, y se crearon las tablas, y los índices, y los stored procedures”.
 Partir de crear un esquema inicial y añadir scripts de cada modificación,
versionados en un script maestro que los ejecute en orden.
 “Y a la tabla de empleados le quitó una costilla, y creo la vista de departamento IT”.

▊▊▊▊▊▊▊▊ · · 80%

A. El resultado de la compilación no va al control de código
 ¿Si el código no sirve para compilarlo, para qué lo guardas?
 Ni *.class, ni *.jar, ni *.obj, ni *.exe, ni *.gaitas.
 No tiene sentido y sólo vas a fastidiar a tu equipo.
 Usa las herramientas para ignorar extensiones y directorios.
 Cuando incorpores ficheros, haz un clean previo del proyecto.

 Guarda lo mínimo que define el proyecto.

 Y si hay que guardar un resultado final:
 I:_exeExxxxxEntregados


▊▊▊▊▊▊▊▊▊ · 90%

A. Tu configuración personal no le importa a nadie
 Entraría en conflicto con la configuración de otros.
 Depende de la tecnología.
 Ejemplo Java:
 pom.xml si es necesario para Maven
 .project y .classpath de Eclipse no se requieren pudiendo importar el proyecto.


▊▊▊▊▊▊▊▊▊▊100%

A. Las dependencias tambien deben estar ahí.
 O sólo funcionará en tu máquina.
 A no ser que uses Maven u otro gestor de dependencias.
 Por si las moscas, una copia en I:_exeExxxxxFuentesdependencias
 Y si hace falta, versionarla.


5. Los 10 mandamientos: Bonus track
▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊

A. Todo commit se asocia a una unidad de trabajo del proyecto.

 El comentario del commit incluye el identificador de la unidad.
 El id de un bug.
 El código de una funcionalidad.

 Facilita encontrar todas los cambios relacionados con un tema
 “¿Quién #@$%!!! tocó qué y cuándo y por qué para hacer ésto?”
 Bastará con buscar el identificador de la tarea.


▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊

A. Todo commit se asocia a una unidad de trabajo del proyecto.
 Ejemplo:
 Las tareas tienen un código identificativo.


▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊

Todo commit se asocia a una unidad de trabajo del proyecto.
 Ejemplo:
 Encontrar cambios buscando por el código de tarea.


▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊

¿Cosas fuera de control de código?
 Si, una: Las pruebas de concepto.
 Ficheros zip que con un proyecto que demuestra una solución.
 Con un documento que explique por qué se hizo y como.
 Crean Knowledge Base.


▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊

Subversion best practices
 Varias fuentes adicionales:
 http://solowebstartup.com/top-18-subversion-best-practices
 http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html


6. EL CONTROL DE CÓDIGO
ESTÁ BAJO CONTROL

6. Control bajo control

#chucknorrisfacts


StatSVN
 http://www.statsvn.org/
 So, what is StatSVN? Great statistics for SVN!
 StatSVN retrieves information from a Subversion repository and generates
various tables and charts describing the project development, e.g.
 Timeline for the lines of code
 Lines of code for each developer
 Activity by Clock time
 Authors Activity
 Author activity per Module
 Author Most Recent Commits with links to ViewVc
 Stats per directory
 File count
 Average file size
 Largest files
 Files with most revisions
 Directory Sizes
 Repository Tags Number of LOC per version.
 Repository tree with file count and lines of code
 LOC and Churn the evolution of LOC and the amount of change per day
 Repo Map the dynamic hierarchical view of your repo for the last 30 days


http://www.statsvn.org/demo/ruby/


7. ¿DONDE ESTA EL SUBVERSION?

7. ¿Dónde está el Subversion?
Varias opciones:
 Usar el del propio cliente.
 Caso de las organizaciones que controlan su código de cerca.
 Ejemplo: UOC


Varias opciones:
 Usar un hosting externo.
 Caso de cliente que quiera su propio repositorio sin infrastructura propia.
 Ejemplo de hosting: xp-dev.com, unfuddle.com.
 Facilitan algunas herramientas extra de gestión de proyecto:
 Timeline.
 Tickets.
 Wiki.


Varias opciones:
 Acceder al Area 51 de NexTReT.
 http://area51.nextret.net/ desde red interna.
 http://area51.nextret.net:xxxx/ desde Internet (seguridad y/o IP reciclada).
 Autenticación con login/password de red corporativa.


Varias opciones:
 Acceder al Area 51 de NexTReT.
 Un repositorio por año /repo12
 Un directorio raíz por proyecto /Exxxxx
 Pedir a dsv@nextret.net (futuro: sau)
 StatSVN on the way…


8. INTEGRACION CONTINUA

8. Integración continua

La integración continua es la ejecución de todas estas tareas…
 Obtener la última versión del código del proyecto.
 Compilarlo y generar binarios.
 Realizar pruebas unitarias y de integración.
 Correr análisis de métricas de calidad del código.
 Enviar correos con informes.

… cada vez que un desarrollador hace commit de un cambio.
 ¿Cada vez que se envía un commit?
 ¡¿A MANO?!

¡Un momento!



“Never send a human to do a machine’s job”



“Throughout human history,
we have been dependent on machines to survive.”



La integración continua

 Permite asegurar
 continuamente
 de forma automatizada
 que los cambios que lleva cada uno de los desarrolladores en un equipo
de trabajo no presenta problemas de integración con el código del resto
del equipo.
 Es una de las prácticas propuestas por las metodologías ágiles.

El objetivo es trasladar la variable del esfuerzo de integración
de la parte final del desarrollo para repartirlo a lo largo de todo
el proyecto.


Ventajas
 Minimizar los tiempos y la problemática de la integración en los equipos
de desarrollo.
 Automatizar la construcción y paso de pruebas en cada cambio realizado
en el repositorio de código
 Mejora la eficiencia del equipo de desarrollo.
 Automatizar herramientas de análisis de calidad del código, como Sonar,
Checkstyle, PMD, Cobertura, etc…
 Automatizar pasos a entornos de pruebas, como entornos de
preproducción.
 Se identifican errores de entorno en fases tempranas.
 Automatizar tareas de gestión de la configuración, como etiquetado de
versiones de desarrollo
 Minimiza el tiempo de realimentación con el cliente.
 Hacer visible al equipo de desarrollo el estado del proyecto.
 Aumentar la confianza en el código entregado al repositorio.


Requiere que el build del sistema esté automatizado y pueda
ejecutarse con un único comando
 Implica gestionar las dependencias.
 La mejor herramienta de gestión de dependencias es Maven.

 Beneficios de Maven:
 Gestión automática de dependencias:
 Artefactos públicos/privados y otros frameworks (Spring, JPA, JSF...)
 Ciclo de vida repetible:
 Construcción, pruebas, empaquetado, despliegue, etc..
 Independiente del IDE de desarrollo empleado.
 Mejora la carga de los entornos de desarrollo locales y reduce el
tiempo de creación inicial y configuración de dichos entornos.
 Habilita la creación de repositorios corporativos de dependencias y
artefactos, mejorando la organización interna.


Self-test del código

 Implica que el código desarrollado tenga siempre al menos pruebas
unitarias que cubran el mayor porcentaje posible del mismo.

 Es posible aplicando metodología TDD: Test Driven Development.

 TDD garantiza que el juego de pruebas evoluciona acorde a la evolución
del sistema, al ser necesario plantear la prueba antes del componente a
desarrollar.

 La integración continua potencia sus beneficios al garantizar la ejecución
automática de ese juego de pruebas de forma continua.


Self-test del código

 El punto de partida son los frameworks XUnit, que permiten reducir el
esfuerzo en la creación de los componentes de prueba:
 Test Unitarios: Ej: JUnit.
 Test de Integración: Ej: DBUnit.

 La integración continua permite también automatizar:
 Pruebas de rendimiento, Ej: JMeter, JUnitPerf.
 Pruebas automáticas de interfaz de usuario, Ej: Selenium, Sahi, Watir.

 El punto de partida son los frameworks XUnit, que permiten reducir el
esfuerzo en la creación de los componentes de prueba:
 Test Unitarios: Ej: JUnit.
 Test de Integración: Ej: DBUnit.

 La integración continua permite también automatizar:
 Pruebas de rendimiento, Ej: JMeter, JUnitPerf.
 Pruebas automáticas de interfaz de usuario, Ej: Selenium, Sahi, Watir.



Entrega continua de cambios

 Es necesario establecer un punto único como repositorio del sistema en
desarrollo, con la estructura adecuada, normalmente:
 Rama principal con la versión actual en desarrollo. (HEAD / trunk)
 Rama de mantenimiento de la última versión en producción.

 Los miembros del equipo de desarrollo deben entregar sus cambios cada
vez que esos cambios sean correctos y pasen las pruebas asociadas en
su entorno local, afrontando antes la integración con cambios conflictivos
de otros miembros del equipo

 En todo momento, el servidor de integración continua construye de
forma completa el sistema en cada cambio del repositorio, avisando
de los errores a los autores de los cambios entregados.



Servidor de integración continua
 Existen múltiples implementaciones disponibles: Hudson, Continuum,
Cruise Control...
 Detectar cambios y descargar el código desde el repositorio de
versiones.
 Lanzar la construcción del sistema, y la ejecución de las pruebas.
 Ejecutar automáticamente herramientas de análisis de la calidad del
código.
 Publicar los artefactos generados en la construcción.
 Etiquetar el código tras una construcción exitosa.
 Ante errores, notificar al equipo de desarrollo de los mismos.
 Gestionar el histórico de construcciones y de estadísticas de pruebas.



Métricas
 Es importante disponer de herramientas que permitan automatizar
análisis de código para gestionar:
 Nomenclaturas requeridas por arquitectura y metodología.
 Buenas prácticas.
 Código repetido.
 % de código cubierto por pruebas.
 Parámetros de complejidad de clases y métodos.
 % de código comentado.
 Evolución de las métricas a lo largo del tiempo.



Salida de las métricas
 Cuadro de mando



Escenario de aplicación



¿Un servidor?

 Cualquier contenedor de servlets Java (Tomcat, JBoss, Jetty, OC4J…)
 $ nohup java -jar hudson.war > $LOGFILE 2>&1

 Posibilidad de arquitectura de maestro que delega a esclavos.

 Capacidad de desplegar esclavos en instancias EC2 de Amazon.
 10 céntimos la hora.

 ¿Maestro en Area 51, esclavos en cloud?


“Pero yo trabajo en .Net”
“Pues vale”

 Obligatorios:
 MSBuild plugin
 http://wiki.hudson-ci.org/display/HUDSON/MSBuild+Plugin
 NUnit plugin
 http://wiki.hudson-ci.org/display/HUDSON/NUnit+Plugin
 Opcionales:
 Violations plugin
 http://wiki.hudson-ci.org/display/HUDSON/Violations
 Open Tasks plugin
 http://wiki.hudson-ci.org/display/HUDSON/Task+Scanner+Plugin


Microsoft Team Foundation Server 2010


EPÍLOGO

Epílogo

El código fuente de xyz@nextret.net apareció de casualidad

 En un backup de un servidor virtual a punto de ser borrado.
 A tiempo de no tener que tomar decisiones drásticas.


Epílogo

Las marmotas de abc@nextret.net se han hecho famosas

 Si el 2 de febrero la marmota ve cajas de pizzas en tu oficina,
el proyecto no cumplirá los plazos de entrega .


Epílogo

Ningún pulpo fué maltratado en la elaboración de este documento.


Cuando volver a casa y olvidarse de todo significa, literalmente eso.
Nadie sabe cuando va a surgir un problema, aunque está claro que son inevitables.
Sin embargo, resolverlos es precisamente una de nuestras especialidades.
Y será una de las que más aprecies. Pregúntale a nuestros clientes.

Paseo Bonanova, 9 - 08022 Barcelona - T. 932 541 530
www.nextret.net - info@nextret.net
Fortuny, 3 - 28010 Madrid - T. 917 021 645

Bootcamp2012dsv code management continuois integration

Recommended

Recommended

More Related Content

Similar to Bootcamp2012dsv code management continuois integration

Similar to Bootcamp2012dsv code management continuois integration (20)

Bootcamp2012dsv code management continuois integration