¿Cuál es el uso más inteligente del repositorio de fuentes que haya visto alguna vez?

Question

Esto en realidad se deriva de mi pregunta anterior, en la que una de las respuestas me hizo preguntarme cómo las personas están utilizando el repositorio scm/de diferentes maneras para el desarrollo.

Answer 1

Pre-tested commits

Antes (TeamCity, construir manager):

El concepto es simple, el sistema de construcción se erige como un obstáculo entre su tronco cometer entrar y sólo después de que el sistema de construcción determina que su compromiso no interrumpe las cosas, ¿permite que el compromiso se introduzca en el control de versiones, donde otros desarrolladores sincronizarán e integrarán ese cambio en sus copias de trabajo locales

Después (utilizando un DVCS como Git, que es un repositorio de código fuente):

Mi flujo de trabajo con Hudson para las confirmaciones previamente probados implica tres repositorios Git separadas:

• mi repo local (local) ,
• el repositorio canonical/central (origen)
• y mi repositorio "legible por el mundo" (dentro del firewall) (público).

Para comprobaciones comprobadas previamente, utilizo una rama en constante cambio llamada "pu" (actualizaciones potenciales) en el repositorio de lectura mundial.
Dentro de Hudson creé un trabajo que sondea el repositorio (público) legible por el mundo para los cambios en la rama "pu" y dará inicio a las compilaciones cuando se presionen las actualizaciones.

mi flujo de trabajo para la toma de un cambio desde el inicio hasta el origen es:

* hack, hack, hack 
* commit to local/topic 
* git pup public 
* Hudson polls public/pu 
* Hudson runs potential-updates job 
* Tests fail? 
     o Yes: Rework commit, try again 
     o No: Continue 
* Rebase onto local/master 
* Push to origin/master 

El uso de este pre-prueba comprometer el flujo de trabajo puedo descargar la mayoría de mis prescripciones de ensayo para clúster del sistema de acumulación de máquinas en lugar de ejecutarlas localmente, lo que significa que puedo pasar la mayor parte de mi tiempo escribiendo código en lugar de esperar que las pruebas se completen en mi propia máquina entre las iteraciones de codificación.

---

(Variación) Private Build (David Gageot, Algodeal)

mismo principio que el anterior, pero la acumulación se realiza en la misma estación de trabajo que el utilizado para desarrollar, pero en una clonados repo:

¿Cómo no utilizar un servidor de CI a largo plazo y no sufrir el aumento del tiempo perdido mirando las compilaciones localmente?

Con git, es pan comido.
Primero, 'clonamos' el directorio de trabajo en otra carpeta. Git hace la copia muy rápidamente.
Próximos tiempos, no necesitamos clonar. Sólo dile a Git obtener los deltas. Resultado neto: clonación instantánea. Impresionante.

¿Qué tal la consistencia?
Haciendo un simple 'git pull' desde el directorio de trabajo se realizará, usando los compendios del delta, que los cambios ya se realizaron en el repositorio compartido.
Nada que hacer. Impresionante de nuevo.

Por supuesto, mientras la compilación se ejecuta en el segundo directorio, podemos seguir trabajando en el código. No hay necesidad de esperar

Ahora tenemos una versión privada sin mantenimiento, ninguna instalación adicional, que no dependa del IDE, se ejecutó con una sola línea de comando. No más construcciones rotas en el repositorio compartido. Podemos reciclar nuestro servidor CI.

Sí. Has escuchado bien. Acabamos de construir un CI sin servidor. Cada característica adicional de un servidor de CI real es un ruido para mí.

#!/bin/bash 
if [ 0 -eq `git remote -v | grep -c push` ]; then 
    REMOTE_REPO=`git remote -v | sed 's/origin//'` 
else 
    REMOTE_REPO=`git remote -v | grep "(push)" | sed 's/origin//' | sed 's/(push)//'` 
fi 

if [ ! -z "$1" ]; then 
    git add . 
    git commit -a -m "$1" 
fi 

git pull 

if [ ! -d ".privatebuild" ]; then 
    git clone . .privatebuild 
fi 

cd .privatebuild 
git clean -df 
git pull 

if [ -e "pom.xml" ]; then 
    mvn clean install 

    if [ $? -eq 0 ]; then 
    echo "Publishing to: $REMOTE_REPO" 
    git push $REMOTE_REPO master 
    else 
    echo "Unable to build" 
    exit $? 
    fi 
fi 

---

Dmitry Tashkinov, que tiene un interesting question on DVCS and CI, se pregunta:

No entiendo cómo "Hemos construido un CI sin servidor" coherentes con el estado de Martin Fowler:
"Una vez que he hecho mi propia compilación de una copia de trabajo correctamente sincronizada, puedo finalmente comprometer mis cambios en la línea principal, que luego actualiza el repositorio. Sin embargo, mi compromiso no termina mi trabajo. En este punto, compilar de nuevo, pero esta vez en una máquina de integración basada en el código de la línea principal. Solo cuando esta construcción tenga éxito podemos decir que mis cambios han terminado. Siempre hay una posibilidad de que me haya perdido algo en mi máquina y el repositorio no se haya actualizado correctamente."
qué ignoras o dobla

@Dmitry:? No ignoro ni doblar el proceso descrito por Martin Fowler in his ContinuousIntegration entry
Pero hay que darse cuenta de que DVCS adds publication as an orthogonal dimension to branching
El CI sin servidor descrito por David es.. sólo una aplicación del proceso de CI general detallado por Martin:. en lugar de tener un servidor de CI, se presiona a una copia local donde un CI local que va, a continuación, se presiona código "válido" para un acuerdo de recompra centro

@ VonC, pero la idea era ejecutar CI NO localmente particularmente para no perder algo en transición entre las máquinas.
Cuando usa el llamado CI local, puede pasar todas las pruebas simplemente porque es local, pero luego se descompone en otra máquina.
¿Entonces es integeración? No estoy criticando aquí en absoluto, la pregunta es difícil para mí y estoy tratando de entender.

@Dmitry: "So is it integeration"?
Es un nivel de integración, que puede ayudar a deshacerse de todas las comprobaciones básicas (como formato, código, detección de análisis estático básico, ...)
Como tiene ese mecanismo de publicación, puede encadenar ese tipo de CI a otro servidor de CI si lo desea. Ese servidor, a su vez, puede impulsar automáticamente (si esto todavía es rápido) al repositorio "central".

David Gageot no necesitaba un nivel extra, siendo ya en el objetivo en términos de arquitectura de despliegue (PC-> PC) y sólo necesitaba ese tipo básico del nivel de CI.
Eso no le impide configurar un servidor de integración de sistema más completo para realizar pruebas más completas.

Answer 2

Definitivamente Polarión Pista & Wiki ...

la base de datos de seguimiento de errores y wiki se almacena en la subversión a ser capaz de mantener un historial de revisión completa.

http://www.polarion.com/products/trackwiki/features.php

Answer 3

Mi favorito? Una herramienta inédita que utilizó Bazaar (un DSCM con un manejo de renombrado explícito muy bien pensado) para rastrear datos estructurados en árbol al representar el almacén de datos como una estructura de directorio.

Esto permitió que un documento XML se bifurcara y combinara, con todas las bondades (detección y resolución de conflictos, flujo de trabajo de revisión y, por supuesto, registro de cambios y similares) facilitado por el moderno control de fuente distribuida. Dividir los componentes del documento y sus metadatos en sus propios archivos evitó que la proximidad creara conflictos falsos y de otro modo permitió que todo el trabajo que el equipo de Bazaar implementara en los árboles del sistema de archivos de versiones funcionara con datos estructurados en árbol de otros tipos.