Planeta código

Sponsors

• Vuelos Baratos
• Mercadona Actualidad
• Mercadona Compra Online
• Encuentro
• Oposiciones
• Registra dominio .com
• Cheap car hire Spain
• tattoos

Recapacitando esta mañana, este post no puede empezar sinó felicitando(me) los recién cumplidos 23 añitos que hago hoy!! Impresiones sobre el próximo año, me siento pequeño todavía.

Volviendo al post anterior, las primera impresión que he recibido es que los desarrolladores españoles no están para nada acostumbrados a los sistemas de build y esas cosas. Si, se que los de java soleis utilizar ant a diario. Si, se que la legión linuxera está empapada de make hasta los codos. Pero los "pobres" desarrolladores de .NET que intentamos sobrevivir a diario todavía nos falta un camino bien grande por recorrer. Por ello, creo que es mejor pegarle un repaso a NAnt, antes de seguir con la integración contínua. No entraremos en temas técnicos, para eso ya hay infinidad de tutoriales.

Un sistema de Build para equipos de desarrollo pequeños.

Vamos por partes. Has decidido ponerte manos a la obra y decides productizar tu aplicación. Cosas que debes tener en cuenta antes de hundirte por intentar hacer las cosas a lo grande:

1. Si tu empresa es pequeña y no puede permitirse lujos de personal, evita caer en la tentación de emplear tres ramas de código (main, qa y release) y cíñete a dos de ellas: main y release. Te recuerdo que seguramente contarás con 3 o 4 desarrolladores, poco tiempo y ningún departamento de calidad. Así pues, establece normas de uso para cada rama: main se utiliza para añadir nuevas características; cuando lo has sometido a pruebas, funciona y no hay más cambios, integra en release. La rama de release utilízala solo para solucionar problemas y fallos. Cada rama ha de mantener su propio número de versión diferente, y una rama puede contener más de una versión logicamente. Típicamente, cuelga tus archivos sobre\\depot\main integra nuevas cosas en \\depot\release y si encuentras un fallo en release, mezcla hacia main. Necesito una traducción de la documentación de perforce ya. (mezclar == merge ?¿?)
   
   
2. He visto en algunos sitios web, que utilizan el número de versión de los ensamblados como número de versión de tu producto. Es una mala elección. Intenta mantener las dos cosas separadas. Así sabrás, cuando realices cambios, qué versión de qué componente es afectada en cada nueva versión de tu producto. Cuando se desarrollan componentes, siempre estas mirando a la reutilización, asi que no los trates como si fueran parte de tu solución (aunque realmente lo sean).
   
   
3. Ejecuta dos builds separados. Uno en main, y otro en release. Obviamente si utilizas NAnt lo lógico sería mantener estos archivos en el propio control de código fuente. Un archivo de ".build" por componente es perfecto. Deberías mantener un archivo fuera del control de código fuente que te permita iniciar el build. Por ejemplo, crea un directorio en c:\build\ que se ejecute con nant release o nant main. Cada uno de estos targets realizará las siguientes acciones:
   
   
1. Obtener el número actual de versión de build.number.release o build.number.main y crear un directorio correspondiente (c:\build\release\1.0.43.456\, por ejemplo).
   
   
2. Crear la estructura base dentro del directorio, a saber, tres directorios: src donde guardaremos los fuentes provenientes de perforce (incluidos archivos de build); setup, donde podemos guardar el instalador de la versión actual (Inno Setup o NSIS funcionan de maravilla y son gratuitos); y web, donde podemos en el caso de que sea una aplicación web, desplegarla y crear un directorio virtual que apunte siempre a la última versión. Útil si necesitas que alguien vea el progreso.
   
   
3. Sincronizar la parte del depot que sea necesario y copiarla al src actual. En NAntContrib existe una tarea para ello, pero no funciona del todo como debería. Mejor utiliza exec y pon la línea de comandos a mano que no es tan costoso.
   
   
4. Copiar de src los archivos .build de los componentes. Lo mejor, que pruebes a construir la aplicación primero y llames en este punto al archivo que coordina ese proceso. <nant etc...
   
   
4. Intenta escribir test para los componentes más críticos de tu aplicación. Si utilizas NUnit, puedes integrar la fase de validación de las pruebas en el proceso de build, fácilmente con NAnt.
   

Comentarios finales. Cada día creo que enreveso más el post. Lo siento! En untidy.net existen tareas para NAnt útiles relacionadas con Inno y cvs, aunque la última versión no me permitía guardar el setup donde yo quería y paso de modificar el .iss "al vuelo" durante el proceso de generación (con lo fácil que es iscc piloto.iss /Odir). De cualquier modo, cíñete a la regla más efectiva de este planeta: Si ha estado funcionando desde hace años asi, y realmente no existe la necesidad de modificar tu sistema de desarrollo, no lo hagas. Cuando comiences con cualquier nueva práctica, intenta empezar con un proyecto piloto (desechable) que te permita evaluar los riesgos reales a los que vas a someter a tu empresa con todo esto. Después puedes aplicarlo a un proyecto pequeño. El proyecto piloto podría ser una aproximación a la arquitectura de tu producto, asi aprovechas y evalúas opciones. Una semana de piloto y dos meses de microproyecto son suficientes para darte ese empujoncito y desmarcarte del resto de empresas de este país. Ahora controlas tu producción. Felicidades.