tfs msbuild build-automation team-build

tfs - ¿Cuáles son las cosas interesantes y geniales que haces durante la automatización de compilación?



msbuild build-automation (30)

Solo tengo curiosidad por ver qué hacen los demás durante la automatización de compilación además de las tareas habituales de compilación, compilación, pruebas de ejecución, etc. que pueden ser útiles e inspiradoras para que otros las consideren y analicen, como:

  • Generando documentación de código
  • El uso de métricas de código para medir la calidad de construcción y falla la compilación si se infringen las métricas establecidas.

¡Estoy realmente sorprendido de que nadie haya mencionado actualizar los archivos de configuración! Actualizamos nuestros archivos de configuración b en función del entorno que estamos creando para usar el script de compilación. Ahorra al menos 20 minutos para reemplazar todos los connectionStrings y appSettings. Otras cosas que hacemos son:

Actualizar el número de versión
Mover a servidores de prueba
Ejecutar análisis de código
Estado de creación del correo electrónico
Ejecutar algunos scripts de base de datos

¿Qué hay de la incrustación de una marca de tiempo de compilación en cada imagen construida?

<ItemGroup> <StampFile Include="BuildTimestamp.cs"/> </ItemGroup> <Target Name="BuildTimestamp" Outputs="@(StampFile)"> <Message Text="Building Timestamp..." /> <Touch AlwaysCreate = "true" Files="@(StampFile)" /> <WriteLinesToFile File="@(StampFile)" Lines=''public static class Build { public static string Timestamp = "%(StampFile.CreatedTime)" %3B }'' Overwrite="true"/> </Target>

Puedes ampliar esto para incluir el nombre de la máquina, la fase de la luna, etc.

Además del control de versiones, firma y prueba, etc., ya mencionado aquí varias veces, también:

  • ejecutar spdisposeCheck para sharepoint-dll''s
  • ejecute sigcheck (desde sysinternals) para crear una buena descripción general de las versiones y los certificados aplicados

Algunas cosas que hemos hecho:

  1. Firmar digitalmente todos los ex
  2. Archivo pdbs
  3. Crear instaladores usando WIX
  4. Produzca archivos .iso completos para software distribuido en CD o DVD

Aplicamos una firma digital a todos los binarios que producimos. El script de compilación lo hace automáticamente.

Aquí hay algunas cosas que generalmente tengo en Integración Continua :

  • computación de métricas de código y estadísticas de rendimiento (capturadas por nuestro marco, mientras se ejecutan las pruebas;
  • ejecutar pruebas de calidad de código que apliquen ciertas pautas de desarrollo (es decir, nombres de clases, inmutabilidad, referencias permitidas);
  • actualizar la documentación en línea que se genera a partir del código;
  • poner paquetes de instalación (WiX y ClickOnce) en el servidor de implementación y actualizar el manifiesto necesario para las actualizaciones automáticas;
  • actualización de la página "Descargar" para proyectos de código abierto;
  • notificando a todas las partes involucradas sobre la construcción y los resultados.

Código Administrado:

  1. Actualice todos los archivos AssemblyInfo con una versión coherente
  2. ¡Ejecute StyleCop y FxCop y compruebe que el código sea hermoso y se comporte bien!

Código nativo:

  1. Ejecute depends.exe en los binarios y compruebe que no se hayan introducido dependencias en el tiempo de ejecución de depuración, que ocurre con demasiada frecuencia
  2. Utilice manifest.exe para volcar los archivos de manifiesto y comprobar las dependencias de depuración: ¡esas cosas llegan a todas partes!
  3. Generar enlaces de python para código C ++ utilizando SWIG

Construimos proyectos BizTalk 2006 :)

Cree un informe para cualquier TODO / FIXME, etc. que pueda estar diseminado por el código.

Disparando los ejecutables a http://virustotal.com para una exploración de virus contra todos los principales motores antivirus.

No es que pensemos que nuestros excombatientes contienen virus, pero a veces obtienes un resultado falso positivo y no quieres que sea un cliente que lo encuentra. 8-)

Ejecutando pruebas unitarias y herramientas de análisis de código como NDepend, Gandarme. Los resultados son publicados por CC.Net

El nuestro tiene una cuenta de Twitter para que podamos verificar su estado en cualquier momento y desde cualquier lugar

Estas son algunas cosas que he hecho, hago o tengo previsto hacer:

  • Actualice un semáforo (utilizando un dispositivo X10) para indicar el estado de compilación (verde = bueno, amarillo = edificio, rojo = ¡gritos!).
  • Genere documentación de código, luego actualice la wiki del proyecto con la documentación.
  • Otras actualizaciones de wiki del proyecto, como publicar el número de versión actual, proporcionar un enlace de descarga, etc.
  • Despliegue hacia (y retroceda si es necesario) un servidor de prueba donde se realizan las pruebas manuales. Normalmente he hecho esto usando VMWare, por lo que el "despliegue" es realmente la creación de una nueva instancia de máquina virtual.
  • Mueva automáticamente los tickets que están "pendientes de compilación" a QA para probarlos.
  • Cree informes de defectos para pruebas fallidas, compilaciones fallidas y advertencias del compilador.
  • Etiquete la compilación en el control de versión (también aplique información de versión).
  • Programe una revisión después de X o más compilaciones fallidas dentro de Y días. (por ejemplo, si tres fallas ocurren en una semana, tenemos que reunirnos para descubrir qué está pasando)
  • Programe una fiesta de "pizza y cerveza" por semanas sin errores.
  • ¡Toca un fuerte "ca-ching"! sonido sobre el sistema PA siempre que se complete una característica que sabemos conducirá a una nueva venta. En mi antigua empresa, a nuestro grupo de ventas le encantó esta función inútil :).

Extraiga una imagen aleatoria de failblog.com para adjuntarla al correo electrónico de "compilación fallida".

Hacemos mucho: con MSBUILD

  • Obteniendo fuentes
  • Actualice la información del conjunto con la marca de tiempo y el último conjunto de cambios en la información del archivo y la versión
  • Compilar:)
  • Ejecutar pruebas con Galio
  • Crear informe de prueba con marca de tiempo actual y publicarlo en IIS
  • Crea un paquete Zip de todos los binarios necesarios
  • Publicar paquetes Zip en SVN
  • Desvincular archivo SLN de TFS
  • Eliminar todos los archivos bin / obj
  • Publicar código fuente en SVN
  • Enviar correo electrónico después del éxito o falla de la construcción
  • Implementar aplicación utilizando scripts NANT

Hacemos un análisis de compatibilidad binaria (usando la reflexión) en contra de nuestro último lanzamiento público para asegurarnos de que no introduzcamos cambios de rotura binarios por accidente. Cada vez que nos vemos obligados a realizar un cambio radical, agregamos la API específica a la lista de "cambios de interrupción aceptados" para que la siguiente compilación pueda omitir las pruebas. Cuando llega el momento del lanzamiento, tenemos una lista completa de las API que se rompen en la nueva versión.

Implemente sitios web directamente para probar servidores de implementación.

No he leído más de la mitad de las respuestas aquí, pero espero que algunas de ellas sean "nuevas":

  • Instalación y actualización de una versión anterior para verificar las diferencias de archivos de una nueva instalación (prueba nuestra configuración de actualización de implementación)
  • Desplegar nuestra aplicación central y adaptadores de sistema externos a un Jboss personalizado (incluido en el proyecto / versión), iniciarlo y ejecutar suites de prueba SoapUI para verificar la funcionalidad de extremo a extremo (también una prueba adicional para nuestra automatización de implementación)
  • Aplique scripts delta a una versión de base de datos anterior y luego realice una comparación estructural con una nueva instalación para que se creen nuevas tablas, columnas, etc. durante las actualizaciones
  • Publique nuestra documentación de lanzamiento en Confluence (básicamente ejecutamos nuestro script de lanzamiento completo cada noche), como una vista previa de la próxima versión del tronco

Para Java, también puede usar Ivy para tomar automáticamente cualquier biblioteca faltante. Por ejemplo, si usa Hibernate, puede o no querer incluir esas bibliotecas en su versión.

Para el desarrollo de Java utilizamos:

  • JUnit complementado por Cobertura (Cobertura identifica qué partes del código carecen de cobertura de prueba)
  • Buscar errores: herramienta que recorre el código buscando errores y vulnerabilidades
  • Herramienta Hudson (consulte hudson.dev.java.net [No puedo publicar hipervínculos todavía!]) Que gestiona la creación y prueba de software. Tiene una característica como el semáforo de AoP (construcción azul exitosa y todas las pruebas de unidad pasaron, la compilación de amarillo exitoso y algunas pruebas de unidad fallaron, la construcción roja falló).

Hudson también

  • Gestiona la creación de software a través de complementos para SVN, Continuus, etc.
  • Mantiene un historial de todas las compilaciones, lo que permite que los resultados de las pruebas de Junit y Find Bugs se muestren en gráficos de tendencias
  • Envía correos electrónicos a todas las partes interesadas cada vez que los resultados de compilación en un estado cambiado (por ejemplo, azul a amarillo, rojo a azul)
  • Toda la información se presenta en una página web interna simple

Restablecer un db de prueba en el paso de compilación posterior:

  • preparar un conjunto de archivos (utilizando la tarea TemplateFile )

Use estos archivos para

  • eliminar la prueba db
  • tomar una copia de seguridad de la base de datos
  • restaurarlo a una nueva instancia db de prueba
  • ejecutar scripts de inicialización sql en db de prueba (usando la tarea Sql.Execute )
  • convertir (usando la tarea Xml.XslTransform ) archivos de datos xml a archivos sql (inserciones)
  • ejecutarlos en la prueba db

Después de esto tenemos una prueba limpia db, con el esquema correcto, todos los datos fijos del db central y luego algunos datos de prueba adicionales.

Sería mejor si el esquema y los datos fijos también estuvieran en archivos de datos y sql comparables, pero eso es WIP. El db central aún no está, pero debe estar en control de fuente.

Sustituye el número de versión en la pantalla de presentación de SVG y luego lo renderiza en Inkscape .

Teníamos un script de compilación que etiquetó automáticamente la compilación y el SVN y desplegó la aplicación en el servidor de aplicaciones de WebSphere.

Tenemos un botón fácil de Staples que hemos conectado para disparar la construcción cuando se presiona.

Tenemos una Nabaztag/tag muestra si se producen errores en el servidor de compilación.

Tenemos una aplicación web y hemos puesto a prueba el rendimiento y pondremos la validación HTML / CSS en los scripts de prueba.

Unas pocas cosas.

  1. Cargue los pdb a Symbol / Source Server <- invaluable para la depuración de los volcados de colapso de winqual
  2. Ejecute pruebas en instaladores implementados en VM través de CC.NET
  3. Cree una VM base para probar a través de CC.NET y desplegarla en todos los QA
  4. Tome una copia de esa imagen de VM y use EggPlant realizar pruebas automáticas de UI

Usamos ''checkstyle'' ( http://checkstyle.sourceforge.net/anttask.html ) para generar un informe para el código que podría registrarse nuevamente y no revisarse (formalmente) antes de que el desarrollador construya. Además, he escrito algunas tareas personalizadas que hacen lo siguiente:

  1. Compruebe las propiedades de conexión de base de datos e intenta establecer una conexión real con el DB (código JDBC simple) e informe si hay algún problema de credencial del usuario, etc.
  2. Agregue el nombre de usuario y la marca de tiempo de la última compilación al código
  3. Envíe una notificación a nuestro cliente de mensajería instantánea corporativa (lista personalizada) con el estado de la compilación

Hay varias tareas más que están allí, pero son específicas de la configuración relacionada con el entorno interno.

Varios proyectos en los que he estado tenían grandes pantallas públicas de quién se registró por última vez y quién rompió la compilación. Hicimos esto con Build-o-matic y escribí Team Piazza para mostrar la misma información para las construcciones de Team City .

Avanzar automáticamente su flujo de trabajo de problemas.

Escribimos un complemento personalizado para nuestro servidor de Bamboo CI que reúne todos los problemas de JIRA relacionados con la compilación (determinado a partir de los comentarios de svn commit) y verifica su estado en JIRA.

Una vez que la construcción tiene éxito (y despliega la aplicación en un servidor en ejecución), cualquier problema en la etapa de flujo de trabajo "en espera de creación" pasa automáticamente a la etapa " creado y disponible para la prueba ", lo que activa un correo electrónico para enviar el probador asignado al problema

Esto significa que nuestros evaluadores reciben correos electrónicos de notificación de problemas no cuando el desarrollador revisa el código, sino cuando la corrección se ejecuta en vivo en un servidor y el verificador realmente puede hacer algo al respecto.