branches - diferencia entre tag y branch svn

¿Mantiene sus herramientas de compilación en control de versiones? (22)

¿Mantiene las herramientas necesarias para construir su proyecto bajo control de versión?

Si lo hace, ¿cuáles son sus pautas para qué herramientas incluir? Supongo que nadie pone Visual Studio en control de versiones, pero ¿qué hay de su unidad de prueba de corredor? ¿El ejecutable de Nant / Ant / Maven?

¿Qué hay de las dependencias externas? ¿Tienes Boost en control de versiones? El JDK? NUnit / JUnit? ¿Dónde trazas el límite aquí?

(Ver también esta pregunta ).

EDITAR: Creo que mi pregunta no estaba del todo clara: no quería saber si los mantenía en control de versiones o en algún disco compartido. Realmente quería saber si revisó las herramientas necesarias para construir un proyecto en el control de la versión junto con el proyecto, de modo que cuando revisó el proyecto, automáticamente obtendría las herramientas.

Como seguimiento general para aquellos que responden no: ¿cuál es su proceso para realizar un seguimiento de esas herramientas? ¿Su script los descarga?

¡Sí! es mi respuesta.

Puse herramientas de compilación como NUnit y NAnt en el control de versiones.

La regla principal para mí es:

El servidor de compilación debe ser capaz de construir la solución.

Y el servidor de compilación que utilizo no tiene instalados NUnit, NAnt, etc.

El servidor de compilación tiene el .NET framework y CruiseControl.NET, y no mucho más ....

Código, compilación, prueba, documentación y cualquier otra automatización. En general, incluso incluyo los cronogramas y cualquier otra documentación relevante para el proyecto en el repositorio.

Y para la mayoría de los proyectos, si tengo la fuente para las bibliotecas dependientes, generalmente los coloco en sus propios repositorios, de modo que puedo rastrear los cambios en ellos a lo largo del tiempo.

En cuanto a las herramientas de preempaquetado en paquetes instalables, las conservo todas en un árbol de directorios grande en un servidor accesible (con las versiones anteriores). De esa forma, puedo señalar a los nuevos desarrolladores en el directorio y decirles qué instalar (y saber que tienen las mismas versiones que el resto del equipo). Yo usaría un repositorio, pero es excesivo, y un sistema de archivos compartido es más fácil de acceder para todos. Las versiones anteriores se guardan en caso de problemas de soporte.

Pablo.

En general, solo agrego elementos al control de versiones que es probable que yo o alguien más con quien trabajo mantengo. Normalmente, un proyecto consume una biblioteca externa; la mayoría de los proyectos que no están en el negocio están reescribiendo las bibliotecas de las que dependen.

Sugiero agregar herramientas que personalizas al control de versiones. Para todo lo demás, puede guardar los paquetes en una ubicación común. No es necesario rellenar su repositorio con un código que nunca cambiará de la distribución estándar.

Hay dos escuelas de pensamiento acerca de esto:

Coloque solo su código fuente en el repositorio.
Ponga todo lo que alguien necesitaría para construir su software, excepto el sistema operativo y el tiempo de ejecución del lenguaje en el repositorio.

Personalmente, me inclino más hacia el n. ° 2 porque facilita que alguien se ponga en marcha con mi código. En cualquier caso, yo diría que si optas por el primer método, al menos debes hacerlo para que una persona pueda obtener las cosas requeridas por el punto 2 y tu código fuente en un solo paso, aunque no necesariamente por control de versión.

Desafortunadamente, el sistema de compilación es una especie de área gris. Personalmente lo dejo a menos que esté usando algo oscuro o no estándar. Y lo que es oscuro y no estándar lo dicta el entorno en el que trabaja. Por ejemplo, si su empresa siempre usa MSBuild pero decidió usar Nant por algún motivo en este proyecto, entonces lo incluiría.

No es la herramienta, sino el guion. Usamos Ant . El script build.xml que dirige el proceso está bajo control de fuente.

No lo hacemos, de hecho, nunca he trabajado para un lugar que sí lo haya hecho.

Mantenemos cosas como Makefiles y compilamos scripts y scripts de prueba en control de fuente, pero nunca compilamos una hormiga o un compilador de C, o tal.

La razón es que, por lo general, es necesario algo más que una simple extracción para que la herramienta de compilación se pueda utilizar, y debe realizar un trabajo de administrador de sistemas para tareas pesadas para mantener múltiples versiones al mismo tiempo o cambiar de una a otra. Así que mantenerlos en control de la fuente resolvería la pequeña parte del problema.

No ponemos Tools en SVN que vinieron de afuera (Visual Studio, Eclipse, CDT-Plugin, ...).

Pero tenemos un gran conjunto de herramientas auto escritas (generadores de código, assmeblies de compilación personalizados para VS y un plugin de Eclipse) donde colocamos la fuente Y los binarios en SVN.

Los motivos de esta decisión son simples técnicos:

Nuestras herramientas son muy pequeñas y no necesitan una rutina de configuración explícita para ejecutarse (por lo que un simple chequeo de svn lo deja con un conjunto de herramientas en ejecución)
Nuestras herramientas cambian con mayor frecuencia que las herramientas de terceros (por lo que no es necesario que le pidamos a nuestros desarrolladores que actualicen las herramientas 3 veces al mes)

No, no lo hago porque utilizo MsBuild, y es parte de .NET Framework de todos modos

No. La mayoría de las tiendas de desarrollo tienen un conjunto de herramientas bastante estándar. Una idea, sin embargo, sería mantener una wiki estándar de "configuración rápida" o similar que vincule profundamente a los instaladores con todas las herramientas de compilación necesarias. Escríbalo para que una persona con relativamente poca experiencia pueda configurar fácilmente una máquina de desarrollo. Una opción más avanzada sería mantener un disco duro virtual estándar que contenga todo.

Sin embargo, mantenemos todo lo demás en control de fuente: todos los scripts de construcción, scripts SQL, dependencias de archivos (es decir, dlls a los que se hace referencia no están instalados en el GAC o archivos de programa), etc.

Normalmente trabajo con eclipse / ant en proyectos Java. No, no mantengo el JDK, Ant o eclipse bajo control de versión, pero:

toda mi fuente
las secuencias de comandos de compilación
todas las bibliotecas de terceros en su versión usada (sí, también junit)

La razón: tengo un sistema de construcción casi autónomo, cualquier sistema con jdk y hormiga instalada podrá construir, sin neccecary de conexión de red (las listas de paquetes para javadoc externo también se registraron). Este puede ser mi macbook, el escritorio de Windows de la empresa, cualquier servidor de construcción continua.

Personalmente, prefiero poner tantas herramientas de compilación como sea posible en el repositorio, pero trazo la línea en el IDE y el compilador.

Me gusta pensar que es una compensación: puedo elegir entre:

Documentar las herramientas necesarias (incluido el mantenimiento de esa documentación) y tener que instalarlas cada vez que necesito volver al proyecto (y multiplicarlo por cada desarrollador adicional en el proyecto)
Poner las herramientas en el repositorio, para que se comprueben automáticamente con la versión correcta.

Para algo como el IDE, es más fácil simplemente documentarlo, y la mayoría de los desarrolladores lo tendrán ya instalado. Para Ant, Nant, JUnit etc. es más fácil incluirlo en el repositorio.

Me gusta especialmente tener Ant / Nant en el repositorio, porque me permite incluir un script go.bat / go.sh como este:

set ANT_HOME=tools/apache-ant-x.x.x tools/apache-ant-x.x.x %*

Entonces siempre puedo pagar un proyecto, ejecutar "ir" y debe construir el proyecto (suponiendo que tenga el JDK / .Net Framework instalado).

Puse scripts de compilación bajo control de versión, pero no herramientas. En general, los archivos de versión que forman parte del núcleo de la aplicación, o es probable que cambien con frecuencia durante la vida del proyecto (y que todos necesitan tener acceso a esos cambios). Esto incluye prácticamente todos los archivos de configuración.

Puse makefiles, scripts de shell y cualquier generador de código que haya escrito en control de versiones. No almaceno archivos binarios en el control de versiones a menos que haya bibliotecas que no se puedan construir fácilmente desde el origen.

Seguimos un camino diferente para configurar una VM en la que hacemos nuestras versiones de lanzamiento. Esto luego se archiva (pero no en el sistema de control de revisiones por algún motivo).

Siempre que tengamos una máquina que pueda alojar la VM, podremos recrear los binarios. Dándonos independencia del sistema operativo subyacente.

Hubo algunos problemas al poner en marcha el administrador de la lista de espera, pero después de eso todo estuvo bien.

Somos una tienda Maven y anteriormente una tienda ANT. En los días ANT verificaríamos las bibliotecas dependientes en la estructura del proyecto. Ahora solo comprobamos los recursos necesarios para compilar la aplicación (pom, código fuente, recursos, etc.) pero definitivamente no hay bibliotecas.

Usamos maven , por lo que solo verificamos el código, las pruebas, los archivos de configuración y, por supuesto, el pom.xml, no libs, no tools.

Conservamos 2 repositorios: el de "rápido movimiento" contiene nuestro código, con ramas para lanzamientos y parches.

El de movimiento lento contiene bibliotecas y herramientas de terceros, incluidas las versiones JDK. No hay ramificación o etiquetado para la mayoría de esto, ya que el código en el otro sabe cómo seleccionar lo que necesita. Dos versiones de la misma biblioteca se registran con diferentes nombres, por lo que ambas estarán disponibles después de la finalización de la compra. Algunas de nuestras propias herramientas de lanzamiento cruzado también se incluyen en este repositorio. Los IDE no están incluidos, ya que no forman parte del proceso de compilación oficial.

Hay dos razones para almacenar herramientas en algún tipo de repositorio:

Cualquier desarrollador puede encontrar fácilmente las herramientas que necesita.
Se puede crear una réplica de cualquier compilación oficial del pasado, de modo que se pueda generar un parche.

Lo que entra en nuestro repositorio:

Cualquier código que escribo o cualquiera de mis alumnos escribe
Todos los Makefiles, scripts de prueba y cosas de ese tipo
Herramientas externas que hemos modificado (normalmente incluimos toda la herramienta, no solo parches) incluida la versión de Make de Andrew Hume

Lo que no entra:

Código fuente para todos los compiladores que estamos usando
Fuente para el caparazón

Si tuviéramos mejores herramientas, lo pondríamos todo en el repositorio. Para obtener un excelente libro sobre cómo hacer esto y realizar un seguimiento de todas las versiones de todo desde el comienzo de los tiempos, consulte el libro en el proyecto Digital SRC Vesta .

Sí, guardo TODO lo que es parte del proceso de entrega de una producción de software en control de versiones.

Estoy realmente sorprendido por todas las respuestas de "no, no hago esto". No puede construir de manera confiable la base de código a menos que tenga las versiones específicas de las dependencias sobre las que se escribió el código. De modo que esto incluiría todas las DLL a las que hace referencia, como las pruebas unitarias y los marcos de burla, los conjuntos de control de la interfaz de usuario, etc.

Un desarrollador debe poder realizar el pago y compilarlo en solo un par de pasos. Hay lugares donde esto lleva todo el día.

No absolutamente no. Nunca. Su VCS solo debe contener su código. Si desea asegurarse de que alguien pueda instalar su código rápidamente, debe proporcionar un sistema de distribución. Alguien que desee instalar su código debe usar una distribución binaria empaquetada o compilar desde un archivo tar de origen. NO deberían estar construyendo desde el VCS. El tarball de distribución es el lugar para construir cosas que son necesarias para que su proyecto se genere, pero que se generan automáticamente o no directamente como parte de su proyecto. NO es el lugar para las dependencias, sin embargo. Si su proyecto necesita las bibliotecas de impulso, debe indicarse en la documentación como una dependencia y su construcción debería fallar si no está instalada. Se espera que el usuario que construye desde el tarball de origen pueda instalar la dependencia. La construcción de usuarios a partir de la distribución binaria empaquetada espera que el sistema de paquetes se ocupe del problema de la dependencia. Se espera que el edificio del usuario del VCS (es decir, un desarrollador) instale las herramientas de compilación necesarias para su proyecto.

Intento usar siempre máquinas virtuales como el sistema de compilación.
Y almacene estos (en el mejor de los casos) para cada proyecto.

El principal problema de usar un tarball o un repositorio con todas sus herramientas:
Cuesta demasiado tiempo instalarlos todos y luego siempre tienes problemas para que vuelva a funcionar después de algunos años.

También descargando a través de un script o simplemente diciendo que la fuente web es inestable después de algunos años, obtendrá un lanzamiento más reciente con otras características y errores.

A veces simplemente falla al instalar el sistema de compilación en una versión más nueva del sistema operativo.
O la versión más nueva de algunas herramientas (como Visual Studio 2025) usará otros archivos de proyecto y la "compatibilidad ascendente completa" falla.

Además, las licencias son problemáticas después de algunos años. ¿Puede obtener su nueva clave de activación en un tiempo razonable? ¿La compañía lo admite de todos modos?

Las máquinas virtuales simplemente contienen todas las herramientas instaladas necesarias y se ejecutan después de unos minutos.
Bien, especialmente si solo quiero cambiar unas pocas líneas de código.