La experiencia duramente ganada me ha enseñado que casi todo pertenece al control de la fuente. (Mis comentarios aquí están coloreados por una década y media en desarrollo para sistemas integrados / de telecomunicaciones en hardware propietario con herramientas propietarias, y a veces difíciles de encontrar).
Algunas de las respuestas aquí dicen "no ponga binarios en el control de fuente". Eso está mal. Cuando trabajas en un producto con un montón de código de terceros y muchas bibliotecas binarias de proveedores, revisas las bibliotecas binarias . Porque, si no lo hace, en algún momento va a actualizar y se encontrará con problemas: la compilación se rompe porque la máquina de compilación no tiene la última versión; alguien le da al nuevo chico los viejos CD para instalar; el wiki del proyecto tiene instrucciones obsoletas sobre qué versión instalar; Peor aún, si tiene que trabajar en estrecha colaboración con el proveedor para resolver un problema en particular y le envían cinco conjuntos de bibliotecas en una semana, debeser capaz de rastrear qué conjunto de binarios exhibieron qué comportamiento. El sistema de control de fuente es una herramienta que resuelve exactamente ese problema.
Algunas de las respuestas aquí dicen "no pongas la cadena de herramientas en el control de fuente". No diré que está mal, pero es mejor poner la cadena de herramientas en el control de la fuente a menos que tenga un sistema de gestión de configuración (CM) sólido como roca . Nuevamente, considere el problema de actualización como se mencionó anteriormente. Peor aún, trabajé en un proyecto donde había cuatro sabores separados de la cadena de herramientas flotando cuando me contrataron, ¡ todos en uso activo ! Una de las primeras cosas que hice (después de que logré que una compilación funcionara) fue poner la cadena de herramientas bajo control de fuente. (La idea de un sistema CM sólido estaba fuera de toda esperanza).
¿Y qué sucede cuando diferentes proyectos requieren diferentes cadenas de herramientas? Caso en cuestión: después de un par de años, uno de los proyectos recibió una actualización de un proveedor y todos los Makefiles se rompieron. Resulta que confiaban en una versión más nueva de GNU make. Así que todos actualizamos. Whoops, los Makefiles de otro proyecto se rompieron. Lección: confirme ambas versiones de GNU make y ejecute la versión que viene con el pago de su proyecto.
O, si trabajas en un lugar donde todo lo demás está completamente fuera de control, tienes conversaciones como, "Hola, el chico nuevo está empezando hoy, ¿dónde está el CD para el compilador?" "No sé, no los he visto desde que Jack renunció, él era el guardián de los CD". "Uhh, ¿no fue eso antes de subir del segundo piso?" "Tal vez están en una caja o algo así". Y dado que las herramientas tienen tres años, no hay esperanza de obtener ese viejo CD del vendedor.
Todos los scripts de compilación pertenecen al control de código fuente. ¡Todo! Todo el camino hasta las variables de entorno. Su máquina de compilación debería poder ejecutar una compilación de cualquiera de sus proyectos ejecutando un solo script en la raíz del proyecto. ( ./buildes un estándar razonable; ./configure; makees casi tan bueno). El script debe configurar el entorno según sea necesario y luego lanzar cualquier herramienta que construya el producto (make, ant, etc.).
Si crees que es demasiado trabajo, no lo es. En realidad ahorra un montón de trabajo. Confirma los archivos una vez al principio del tiempo y luego cada vez que actualiza. Ningún lobo solitario puede actualizar su propia máquina y cometer un montón de código fuente que depende de la última versión de alguna herramienta, rompiendo la compilación para todos los demás. Cuando contrata nuevos desarrolladores, puede decirles que revisen el proyecto y lo ejecuten ./build. Cuando la versión 1.8 tiene una gran cantidad de ajuste de rendimiento, y modifica el código, los indicadores del compilador y las variables de entorno, debe asegurarse de que los nuevos indicadores del compilador no se apliquen accidentalmente a las versiones del parche de la versión 1.7, porque realmente necesitan el código cambios que van junto con ellos o ves algunas condiciones de carrera peludas.
Lo mejor de todo es que algún día te salvará: imagina que envías la versión 3.0.2 de tu producto un lunes. Hurra, celebra. El martes por la mañana, un cliente VIP llama a la línea directa de soporte, quejándose de este error supercrítico y urgente en la versión 2.2.6 que envió hace 18 meses . Y todavía tiene que admitirlo contractualmente, y se niegan a actualizarse hasta que pueda confirmar con certeza que el error está solucionado en el nuevo código, y que son lo suficientemente grandes como para hacerlo bailar. Hay dos universos paralelos:
En el universo donde no tiene bibliotecas, cadenas de herramientas y scripts de compilación en el control de código fuente, y no tiene un sistema CM sólido como una roca ... Puede consultar la versión correcta del código, pero proporciona Usted todo tipo de errores cuando intenta construir. Veamos, ¿actualizamos las herramientas en mayo? No, esas fueron las bibliotecas. Ok, regrese a las viejas bibliotecas. Espere, ¿hubo dos actualizaciones? Ah sí, eso se ve un poco mejor. Pero ahora este extraño bloqueo del enlazador parece familiar. Oh, eso es porque las bibliotecas antiguas no funcionaban con la nueva cadena de herramientas, por eso tuvimos que actualizar, ¿verdad? (Le ahorraré la agonía del resto del esfuerzo. Lleva dos semanas y nadie está contento al final, ni usted, ni la gerencia, ni el cliente).
En el universo donde todo está bajo control de origen, revisa la etiqueta 2.2.6, tiene una compilación de depuración lista en aproximadamente una hora, pasa un día o dos recreando el "error VIP", rastrea la causa, corrígelo la versión actual, y convencer al cliente para actualizar. Estresante, pero no tan malo como ese otro universo donde tu cabello es 3 cm más alto.
Dicho esto, puedes llevarlo demasiado lejos:
- Debe tener una instalación estándar del sistema operativo del que tenga una "copia dorada". Documéntelo, probablemente en un archivo README que esté en control de fuente, para que las generaciones futuras sepan que la versión 2.2.6 y anteriores solo se compilaron en RHEL 5.3 y 2.3.0 y más tarde solo se compilaron en Ubuntu 11.04. Si le resulta más fácil administrar la cadena de herramientas de esta manera, hágalo, solo asegúrese de que sea un sistema confiable.
- La documentación del proyecto es engorrosa de mantener en un sistema de control de fuente. Los documentos del proyecto siempre están por delante del código en sí, y no es raro trabajar en la documentación para la próxima versión mientras se trabaja en el código para la versión actual. Especialmente si todos los documentos de su proyecto son documentos binarios que no puede diferenciar ni fusionar.
- Si tiene un sistema que controla las versiones de todo lo utilizado en la compilación, ¡ úselo ! Solo asegúrese de que sea fácil de sincronizar con todo el equipo, de modo que todos (incluida la máquina de compilación) utilicen el mismo conjunto de herramientas. (Estoy pensando en sistemas como el pbuilder de Debian y el uso responsable de virtualenv de python).