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

Más contenido relacionado

Similar a Bootcamp2012dsv code management continuois integration

Bootcamp2012dsv code management continuois integration