build - scripts - ¿Cómo se pone en funcionamiento con un servidor de compilación?

pack de scripts para mta (12)

Creo que todos aquí estarían de acuerdo en que, para ser considerados una casa de software profesional, hay varias cosas fundamentales que debes tener en su lugar.

No hay duda de que una de estas cosas es un servidor de compilación, la pregunta es, ¿qué tan lejos debe llegar?

¿Cuáles son los requisitos mínimos para el servidor de compilación? (En algún lugar para compilar?)
¿Cuál es el objetivo final para su servidor de compilación? (Integración de control de fuente programada, despliegue automático para probar / servidores en vivo)
¿Dónde es un buen lugar para comenzar suponiendo que no tienes nada en este momento?

Sería genial si pudiéramos enumerar algunas tareas sencillas que un desarrollador aficionado podría tener en cuenta para orientarlas en el camino correcto hacia un servidor de compilación completamente funcional.

También sería bueno saber de personas que sienten que tienen una configuración de sistema "completa" que realiza toda la funcionalidad que requieren y cómo se las arreglaron desde cero.

Comience por leer el excelente artículo de Martin Fowler sobre Integración Continua .

Construimos un sistema así para un gran proyecto> 2,000 kSLOC y demostró ser invaluable.

HTH

aclamaciones,

Robar

Diría que tendrías que comenzar implementando una estrategia de compilación para que puedas construir tu código de una manera estructurada. Yo uso NANT.

Para un servidor de compilación básico: utilice una de las ofertas de CI que supervisa el control de origen y desencadena una compilación siempre que se detecte un cambio. por ejemplo: cruiseControl.

Una vez que obtenga la compilación básica, agregue la ejecución de las pruebas de su unidad después de una compilación exitosa.

El sistema más exitoso que he tenido tuvo 3 compilaciones diferentes: - una que activó un check in; todo lo que hizo fue construir el código. - uno bajo demanda que construiría la aplicación, generaría el instalador y luego pondría el instalador en una unidad compartida para que los evaluadores la retuvieran, una compilación diaria que se activa a las 10 p.m. Esto: - ejecutó la generación de código para construir código DB y C # desde un modelo UML - creó el código - creó un nuevo usuario de prueba de verificación de compilación en una instancia de Oracle de prueba - ejecutó el esquema de la aplicación en el DB - cerró un montón de pruebas unitarias - Limpió al usuario de db (si las pruebas fueron exitosas) - ejecutó un análisis de cobertura para generar un informe de la cobertura del código de unidad

El software que utilizamos para esto fue NANT, CruiseControl.NET, un sistema de generación de código personalizado, una aplicación personalizada para construir un esquema de Oracle y NCover para el análisis del código.

En el espacio de Java, he probado la mayoría de los entornos de compilación disponibles. El problema con la compilación automática es que a menudo terminas gastando una buena cantidad de tiempo en el seguimiento. Después de cambiar al bambú comercial de atlassian, descubrimos que tenemos que pasar mucho menos tiempo mimando la caja de construcción, que en nuestro caso resulta ser una muy buena economía. Bamboo también admite clustering, por lo que puede agregar cajas económicas a medida que las necesidades evolucionen.

Estoy usando Cruisecontrol.NET y un buildscript de msbuild.

Puedo usar el buildscript manualmente para poder obtener la última versión de la base de código, construí la base de código muy fácilmente usando la línea de comando. (Esto es muy interesante si está trabajando en una aplicación que consta de múltiples soluciones).

Además de eso, mi servidor de construcción CruiseControl.NET también usa este script. Comprueba un intervalo regular si se han realizado cambios en el control de origen.
Si eso sucede, CC.NET realiza la tarea ''obtener la última'' que he definido en el script de construcción, crea todo, ejecuta pruebas unitarias y realiza un análisis de código estático (fxcop).

Mi ''servidor de compilación'' es solo una estación de trabajo vieja. Es un PIV, 3Ghz con 1 gb de RAM, y hace su trabajo a la perfección.

Una cosa adicional que me parece interesante es tener la capacidad de implementar automáticamente una nueva versión o crear una configuración. Todavía no lo he hecho, ya que no estoy seguro de si es una buena idea, ni he encontrado una buena estrategia para hacerlo ... quiero decir; está implementando una nueva versión de algunos componentes en producción para una aplicación de misión crítica, ¿una buena idea? No lo creo ...

Creo que este es un buen lugar para comenzar: [ http://confluence.public.thoughtworks.org/display/CC/Home;jsessionid=5201DA7E8D361EB164C40E519DA0F0DE][1]

Al menos, ahí es donde comencé a buscar al configurar mi servidor de compilación. :)

[1]: Inicio de CruiseControl

Intente y encuentre algo que se adapte a sus prácticas existentes en términos de construcción; por ejemplo, no va a ser una buena opción intentar usar un servidor de construcción basado en Ant si está usando Maven.

Idealmente, solo debería ser capaz de monitorear su sistema de control de origen, verificar el código, construir, ejecutar algunas pruebas y publicar los resultados sin que usted lo sepa, o al menos no ''hasta que informe un error. Personalmente, sugiero Hudson ( https://hudson.dev.java.net/ ) como un buen punto de partida, ya que es fácil de instalar y ejecutar y tiene una interfaz de usuario decente.

No pude darle todos los detalles sobre cómo configuramos nuestro servidor de compilación (solo estuve involucrado desde el principio), pero:

Comenzamos con un sistema interno, implementado en ASP.NET y un servicio .NET Windows, usando NAnt para hacer las compilaciones reales. En realidad, la mayor parte del flujo de trabajo se implementó en NAnt (por ejemplo, enviar correos electrónicos a personas, copiar cosas, etc.).
Nos mudamos a JetBrains TeamCity (hay una versión de reducción gratuita disponible), que todavía nos está sirviendo bien.

Lo usamos para compilaciones activadas por una confirmación: estas solo crean los binarios y ejecutan las pruebas unitarias. A partir de aquí, podemos hacer una compilación completa, que también hace la MSI. A partir de ahí, tenemos versiones de pruebas del sistema que ejecutan pruebas más exhaustivas, en un entorno creado con máquinas virtuales (con un controlador de dominio separado, un cuadro de SQL Server, etc.). Cuando las pruebas del sistema pasan, la construcción está disponible para nuestro departamento de control de calidad para pruebas manuales y algunas pruebas de regresión que aún no hemos automatizado.

Puedes comenzar investigando el Control de Cruceros .

También hay CruiseControl.net si ese es tu veneno.

Esencialmente, sin embargo, necesitas los siguientes ingredientes:

Un entorno dedicado (Máquina virtual / servidor. No use una máquina de desarrollador, a menos que sea solo usted. Incluso entonces, ejecute una VM si puede. Mucho más fácil moverla a un servidor cuando / si hay una disponible en su organización)
Un sistema de control de origen que admite revisiones etiquetadas / etiquetadas (por ejemplo, Subversion + TortoiseSVN )
Construir scripts Estos pueden ser archivos por lotes que inician las aplicaciones devenv.exe o msbuild.exe con una línea de comando, o puede usar algo como Ant o NAnt .

En este escenario, CruiseControl actúa como el servidor de Integración Continua , y puede asegurarse de que haya realizado las compilaciones mientras verifica su código. Esto significa que usted sabe si la construcción se rompe más rápido que si solo tuviera compilaciones nocturnas. Sin embargo, probablemente también deberías tener compilaciones nocturnas.

Si usa Cruise Control, el lugar para comenzar es Ant build.xml que hace el trabajo manualmente.

Necesitas un sistema de control de versiones que pueda hacer check-out etiquetados.

Necesita pruebas JUnit para ejecutar utilizando la tarea Ant y generar informes HTML.

Hudson es un gran CI.

Operamos la granja localmente, pero comenzamos descargando hudson.war y haciendo

java -jar hudson.war

Se integra con SCM, sistemas de transporte de errores es realmente increíble.

Necesitará un poco de espacio en disco si desea mantener la compilación anterior.

Disfrútelo es la solución de CI más directa hasta ahora.

HTH, Hubert.

Cruise, Maven, Hudson, etc. son geniales, pero siempre vale la pena tener una solución provisional.

Debería tener un archivo por lotes, un script de shell o simplemente instrucciones escritas que le permitan ejecutar una compilación desde cualquier máquina. ¡Hemos tenido servidores de compilación no disponibles en el pasado y la capacidad de cambiar rápidamente a otra máquina fue invaluable!

La especificación de la máquina de compilación no tiene por qué ser importante a menos que tengas un proyecto monstruoso. Intentamos mantener nuestros tiempos de construcción a 10 minutos (incluidas las pruebas unitarias) y tenemos un proyecto bastante grande.

No tengas la tentación de crear o escribir tu propio sistema de compilación porque "ninguna de las herramientas disponibles es lo suficientemente buena". Todos los sistemas modernos de compilación te permiten escribir complementos para hacer cosas personalizadas.

Aproximadamente en orden - mínimo / menos sofisticado a través de más sofisticado

capaz de obtener un conjunto específico de fuentes en cualquier máquina
capaz de construir esa fuente (sin problemas)
capaz de (programar) construir cada noche / o algún otro período definido sin intervención del usuario
Un (o más) servidor de compilación dedicado (no compartido como máquina qa o dev)
capaz de hacer una construcción después de cada check-in / commit
Notificar a las partes interesadas el estado de compilación después de una compilación
Proporcionar estado de compilación en cualquier momento
Crear instaladores como parte de la compilación
capacidad de implementar / vivir si la construcción es buena
Ejecutar pruebas unitarias
Ejecutar pruebas en el producto
Informe los resultados de esas pruebas
Análisis e informes de código estático ... Y la lista sigue y sigue

No tenga miedo de comenzar con archivos por lotes o scripts de shell u otros medios ad-hoc. La gente hizo un software perfectamente bueno antes de la locura de CI. hubo muchos procesos buenos antes de Hudson y Cruise Control - (no los estoy derribando a ellos ni a otros - uso Hudson entre otros) - pero no se pierda el punto - estas cosas están aquí para ayudarlo - no se convierta en un proceso autoritario)

Comenzamos escribiendo scripts por lotes que se ejecutarán en la máquina de desarrolladores. Una vez que tenemos automatizados todos los procesos, los trasladamos al servidor de compilación.

En cuanto a las herramientas, actualmente nos movemos de Cruise Control a TFS.