Pregunta

Si usted está haciendo un proyecto en solitario - se debe utilizar el CI herramientas para construir a partir de un repositorio?He usado Hudson y el Control de Crucero en un ambiente de equipo, donde es esencial para construir tan pronto como nadie comprueba nada.

Creo que el valor de control de versiones es obvio, pero necesito a construir después de cada commit, ya que simplemente se han construido en mi máquina local, y nadie está cometiendo?

¿Fue útil?

Solución

Bueno, yo estoy planeando utilizar una continua integración de la herramienta en un proyecto y yo soy el único desarrollador.La necesidad viene porque

  1. Uno de los objetivos es hacer de la cruz-plataforma, y tener una herramienta de integración ayuda a implicitelly (básico) compruebe su aplicación en varios plataforma una vez que ha empujado a los cambios en la integración del repositorio (o el central, o lo que sea es el que va a ser utilizado como autoridad).
  2. El proyecto se construye a largo plazo, así que voy a tener que trabajar con un equipo más tarde.No estoy de planificación para reclutar a cualquiera, hasta el 2012, por lo que la integración continua cosa se puede esperar, por el momento, hasta que 1.se convierte en la prioridad.

Aparte de la cruz-plataforma y el trabajo en equipo preparación, no veo la necesidad.Lo principal es tener algún tipo de software de control de origen y tienen varios repositorio para mantener copias de seguridad.Que le ayudará a configurar las herramientas de generación en torno a él cuando sea necesario.

Acerca de la construcción de temporización, estoy usando Mercurial y la configuración de una integración del repositorio que no es el trabajo en equipo repositorio.Así, empujar los cambios en el trabajo en equipo repo hasta que siento que es el momento de hacer el sistema de integración de tratar de construir.Luego me empuje desde el trabajo en equipo repo para la integración de repos y que dará lugar a la acumulación.Entonces yo también agregar una secuencia de comandos que se tire el trabajo en equipo repo en la integración de los repos de una vez cada día.

Aquí estoy suponiendo que yo trabajo casi todos los días en mi proyecto, pero no siempre es verdad.Usted tiene que fijar una acumulación de temporización que es relativa a la frecuencia con la que usted necesita construye.En un juego de la empresa donde yo trabajaba antes, hemos utilizado CruiseControle y la construcción de una generación completa de cada hora.Podríamos también la fuerza de una generación cada vez que queríamos, si es necesario.

Para un proyecto de casa, una vez que un día podría ser ya "a menudo".El requisito principal sería la de permitir fácilmente que el usuario de la fuerza de lanzamiento de una generación.

Otros consejos

Después de una breve contemplación, sugeriría que incluso podría ser más importante para un desarrollador en solitario que para un equipo.

En el nivel más básico, un servidor CI demuestra que puede construir su aplicación desde cero desde la fuente comprometida, combinada con un conjunto decente de pruebas, debe demostrar que puede construir y correr desde cero.

Dado que una de las cosas que trato de hacer es asegurarme de que mi compilación incluya un paquete desplegable, también sabe que puede obtener algo para implementar (limpio y de un estado/versión conocido).

De hecho, ahora, cuando realiza archivo | Nuevo proyecto, probablemente debería incluir crear o agregar a su repositorio y configurar su script de compilación de CI y configuración de implementación (incluso si solo es para cerrar un montón de cosas para la implementación de XCopy)


Anexo (2016): hoy en día mi sistema CI también será una parte integral de mi proceso de implementación, por lo que su valor ha aumentado y no voy a ejecutar ningún proyecto entregable sin él. La implementación automatizada del botón de pulsación elimina mucho estrés del proceso y, de alguna manera, forma o forma un servidor de compilación, es parte integral de eso.

Cuando soy el único que se compromete, solo construyo y prueba antes de realmente cometiendo. Normalmente uso un objetivo de makfile como:

make sense

Eso configura, construye, ejecuta todas las pruebas (Valgrind Aking), ejecuta peluchas, etc. Como sé que seré el único que empuja, realmente no necesito el poder de algo como Hudson.

Además, en un entorno en el que tiene varias ramas que alimentan un repositorio principal, si todos siguen el siempre tirón antes de comprometerse o empujar, el servidor CI podría ser un poco exagerado. Una regla bien escrita que el autor de lo que sea que rompiera la última construcción compra pizza el viernes generalmente mantiene las cosas funcionando sin problemas :)

Si entra en una situación en la que un proyecto se divide claramente en subystems que tienen sus propios líderes, usted De Verdad Necesito contemplar el uso de algo como Hudson. Alguien podría probar localmente, perder una carrera con otro subystem y terminar empujando algo tóxico.

Además, si está manteniendo una bifurcación de un proyecto de movimiento rápido (por ejemplo, su propio conjunto de parches al núcleo de Linux), realmente debería considerar usar algo como Hudson, aunque esté 'en solitario' en ese proyecto. Esto es especialmente cierto si se ramifica / vuelve a base directamente desde la línea principal.

No diría que esto es solo una buena ventaja, diría que es vital para la ingeniería de software de alta calidad para los artistas en solitario de EE. UU. La mayoría de nosotros dejaremos que sus estándares de calidad se deslicen un poco si se apresuran si piensan que es bastante fácil de arreglar más tarde. Si compromete software en ese estado, esencialmente tiene una base de código sin valor almacenada en su control de origen.

Si se adhiere correctamente (es decir, no se omite las pruebas y se asegura de que se acumule cada vez que se compromete) CI lo obliga a adherirse a un estándar de mayor calidad de lo que lo haría si lo cometiera de todos modos.

Es importante si desea reducir su tiempo de espera para ver si todo va bien. Aunque puede obtener su IDE para compilar cosas para usted tan pronto como guarde, no ejecuta automáticamente las pruebas unitarias, por lo que tengo mi servidor CI que ejecuta las pruebas unitarias y los informes de cobertura de casos de prueba y otro análisis de calidad de mi código tan pronto como Lo empujé.

El único desencadenante que tengo que hacer es empujar mis cambios actuales al control de versiones y puedo volver a la codificación. Y mientras estoy pensando en la codificación, el sistema CI está ocupado agotando los informes de calidad de larga data que buscaré de una vez en un tiempo cuando mi cerebro vaya a una pausa.

Tengo una máquina VMware separada en la misma computadora portátil que realiza las compilaciones para el código que presiono. Para hacer esto, solo obtengo una imagen VMware Linux llave en mano e instala los Jenkins usando apt-get y hago algunos cambios de configuración menores.

Licenciado bajo: CC-BY-SA con atribución
scroll top