Qual è l'uso più intelligente del repository di origine che tu abbia mai visto?

Question

Ciò deriva in realtà dalla mia precedente domanda, in cui una delle risposte mi ha fatto riflettere su come le persone utilizzano il repository/scm in modi diversi per lo sviluppo.

Answer 1

Pre-tested commits

Prima (TeamCity, costruire manager):

Il concetto è semplice, il sistema di compilazione si erge come un posto di blocco tra il tronco commettere entrare e solo dopo che il sistema di compilazione determina che il tuo commit non rompe le cose che permette al commit di essere introdotto nel controllo di versione, dove altri sviluppatori sincronizzeranno e integreranno quella modifica nelle loro copie di lavoro locali

Dopo (usando un DVCS come Git, che è un repository di origine):

mio flusso di lavoro con Hudson per commit pre-testate coinvolge tre repository Git distinte:

• mio repo locale (locale) ,
• il repository canonico/centrale (origine)
• e il mio repository "world-readable" (all'interno del firewall) (pubblico).

Per i commit pre-testati, utilizzo un ramo in continua evoluzione denominato "pu" (potenziali aggiornamenti) sul repository leggibile a livello mondiale.
All'interno di Hudson ho creato un lavoro che esegue il polling del repository leggibile in tutto il mondo (pubblico) per le modifiche nel ramo "pu" e avvierà i build quando vengono inviati gli aggiornamenti.

mio flusso di lavoro per l'adozione di un cambio da inizio a origine è:

* 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 

Utilizzando questo pre-testato commettere flusso di lavoro posso scaricare la maggior parte dei miei requisiti di prova al gruppo del sistema di generazione di macchine invece di eseguirle localmente, il che significa che posso passare la maggior parte del mio tempo a scrivere codice invece di aspettare che i test vengano completati sulla mia macchina tra le iterazioni di codifica.

---

(Variation) Private Build (David Gageot, Algodeal)

Stesso principio di sopra, ma la costruzione è fatto sulla stessa workstation di quella usata per sviluppare, ma su un clonato repo:

Come non utilizzare un server CI a lungo termine e non subire il crescente tempo perso fissando le build localmente?

Con git, è un pezzo di torta.
In primo luogo, "cloniamo" la directory di lavoro in un'altra cartella. Git fa la copia molto rapidamente.
Le prossime volte, non è necessario clonare. Dì solo di andare a prendere i delta. Risultato netto: clonazione istantanea. Impressionante.

E la coerenza?
Fare un semplice 'git pull' dalla directory di lavoro realizzerà, utilizzando i digest delta, che le modifiche sono già state inserite nel repository condiviso.
Niente da fare. Impressionante di nuovo.

Ovviamente, mentre la build è in esecuzione nella seconda directory, possiamo continuare a lavorare sul codice. Non c'è bisogno di aspettare.

Ora abbiamo una versione privata senza manutenzione, senza installazione aggiuntiva, non dipendente dall'IDE, eseguita con una sola riga di comando. Niente più build distrutte nel repository condiviso. Possiamo riciclare il nostro server CI.

Sì. Hai sentito bene. Abbiamo appena creato un CI senza server. Ogni caratteristica aggiuntiva di un vero server CI è un disturbo per me.

#!/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, che ha un interesting question on DVCS and CI, chiede:

Non capisco come "Abbiamo appena costruito un serverless CI" coerenti con lo stato di Martin Fowler:
"Una volta creata la mia copia di lavoro correttamente sincronizzata, posso finalmente trasferire le mie modifiche nella linea principale, che aggiorna il repository.Tuttavia il mio commit non termina il mio lavoro. costruire di nuovo, ma questa volta su una macchina di integrazione basata sul codice mainline. Solo quando questa build riesce, possiamo dire che i miei cambiamenti sono fatti. C'è sempre una possibilità che mi sia perso qualcosa sulla mia macchina e il repository non è stato aggiornato correttamente."
fare si ignora o piegate

@Dmitry:? Io non ignorare né piegare il processo descritto da Martin Fowler in his ContinuousIntegration entry
Ma bisogna rendersi conto che DVCS adds publication as an orthogonal dimension to branching
Il CI serverless descritto da David è.. solo un'implementazione del processo CI generale dettagliato da Martin: anziché un server CI, si esegue il push di un codice locale su un repository centrale.

@ VonC, ma l'idea era di eseguire CI NOT localmente in particolare per non perdere qualcosa in transizione tra le macchine.
Quando si utilizza il cosiddetto CI locale, è possibile che passi tutti i test solo perché è locale, ma si analizza più tardi su un altro computer.
Quindi è integeration? Non sto criticando qui, la domanda è difficile per me e sto cercando di capire.

@Dmitry: "Quindi è integerazione"?
È un livello di integrazione, che può aiutare a sbarazzarsi di tutti i controlli di base (come problema di formato, stile del codice, rilevamento dell'analisi statica di base, ...)
Dato che si dispone di quel meccanismo di pubblicazione, è possibile concatenarlo di CI a un altro server CI, se lo desideri. Quel server, a sua volta, può spingere automaticamente (se questo è ancora in avanti) al repository "centrale".

David Gageot non aveva bisogno di quel livello in più, essendo già al target in termini di architettura di implementazione (PC-> PC) e aveva bisogno solo di quel tipo di livello di CI di base.
Ciò non gli impedisce di installare un server di integrazione di sistema più completo per test più completi.

Answer 2

Sicuramente Polarion pista & Wiki ...

L'intero database di tracciamento dei bug e wiki viene memorizzato in eversione per essere in grado di mantenere una cronologia completa delle revisioni.

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

Answer 3

Il mio preferito? Uno strumento inedito che utilizzava Bazaar (un DSCM con una gestione di rinomina esplicita molto ben congegnata) per tracciare i dati strutturati ad albero rappresentando l'archivio dati come una struttura di directory.

Ciò ha consentito la ramificazione e l'unione di un documento XML, con tutta la bontà (risoluzione e risoluzione dei conflitti, flusso di lavoro di revisione e, naturalmente, modifica della registrazione e simili) resi agevoli dal moderno controllo del codice sorgente distribuito. La suddivisione dei componenti del documento e dei relativi metadati nei propri file ha impedito la possibilità di consentire alla prossimità di creare falsi conflitti e ha consentito a tutto il lavoro che il team di Bazaar inseriva nella versione degli alberi del filesystem di lavorare con dati strutturati ad albero di altri tipi.