TFS 2010 Più Soluzioni e Costruire con Gated Check-in

Question

Ho due soluzioni nella rispettiva cartella, ad esempio

1. SolutionA\SolutionsA.sln
2. SolutionB\SolutionB.sln

Ogni soluzione ha Gated Check-in costruire configurato;cioèdue definizioni di creare GatedSolutionA e GatedSolutionB.

Ora la situazione è, se controllo i cambiamenti in entrambe le cartelle insieme TFS mostra una finestra di dialogo selezionare la casella di costruire (discesa con GatedSolutionA, GatedSolutionB) per eseguire le modifiche.Il mio changeset ha modifiche di rilievo in soluzione B e non ultime modifiche in Soluzione A.cioèCostruire GatedSolutionB fallirebbe, ma GatedSolutionA sarebbe passata.

Quando si seleziona GatedSolutionA per costruire contro il mio changeset, TFS controlli, che a sua volta lascia la soluzione B è in stato infranto e lo scopo di Gated check-in viene sconfitto per la Soluzione B.

Se cambio il trigger di IC per costruire definizioni, TFS code di entrambe le generazioni.

Quello che sto cercando è lo stesso comportamento, cioèTutte le Gated versioni sono in coda e se uno di loro non riesce, changeset deve essere respinto.

Nota:Non voglio creare una singola definizione di compilazione per entrambe le soluzioni.Inoltre, so che possiamo evitare questo problema possa avvenire, la creazione di due distinti insiemi di modifiche, ma questo in genere accade quando gli sviluppatori non sono consapevoli del fatto che hanno alcuni file in fase di check-in per soluzione a cui stanno lavorando .

Aggiornamento 2019

Dal TFS e Azure DevOps hanno iniziato ad usare GIT e richiesta di Pull - utilizzo di ramo politiche (il master branch) si può aggiungere più di una creazione di controlli ad es.per variazioni di percorso SolutionA\*, BuildA può essere configurato per essere in coda e controllato, e, analogamente, per le modifiche di percorso SolutionB\*, BuildB può essere configurato per essere in coda e controllato, e, di conseguenza, per un commit avere cambiamenti in entrambi i percorsi saranno coda entrambe le versioni per il controllo.Attendere per l'utilizzo di GIT è valsa la pena.

Filiale Politiche: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation

Nota:la documentazione non viene aggiornato per mostrare il percorso di filtro, e il difetto è sollevata su github qui https://github.com/MicrosoftDocs/vsts-docs/issues/3235.Come tale, il filtro è disponibile in Azzurro DevOps e Server.

Answer 1

So che hai detto che "non si vuole creare una singola definizione di compilazione per entrambe le soluzioni," ma davvero sei unica opzione praticabile qui.Quello che vorrei suggerire è di avere due rami, uno per la funzionalità e uno sviluppo per l'integrazione.Avere il vostro lavoro di sviluppatori in funzione del ramo(es) e utilizzare gated check-in (o CI) costruisce per tali soluzioni.Periodicamente unire le modifiche in funzione di filiale(es) in una integrazione ramo che ha un unico gated check-in costruire definizione che costruisce tutte le vostre soluzioni.Che manterrà le versioni di integrazione del ramo pulito.

Answer 2

@Gchaves trovato una soluzione per questo problema, si può andare a "Modifica le Definizioni di compilazione" e "area di Lavoro" scheda se si configura il "Origine Controllo" Cartella all'interno della cartella dove avete SolutionA.

Per esempio, se si dispone di questo tipo di file system:

1. Progetti\SolutionA\SolutionA.sln
2. Progetti\SolutionB\SolutionB.sln

Ora, se si configura "Origine Controllo" Cartella " e "Agente di compilazione Cartella" per Progetti\SolutionA, la Gated check-in verrà attivata solo quando si tenta di checkIn SolutionA, e sarà solo compilare SolutionA.sln (per questo per essere vero si deve avere a che punto basta SolutionA.sln sulla Scheda di Processo ->1.Richiesto->ProjectsToBuild)

E poi si possono avere più soluzioni nella stessa area di lavoro, la costruzione, il controllo e l'etichettatura in modo indipendente:)

Answer 3

Nel costruire la definizione di Processo scheda è possibile scegliere più di una sln a costruire.

Answer 4

Una soluzione a questo problema è per gli sviluppatori distinte aree di lavoro mappata per le soluzioni separate.Se non c'è il codice di sovrapposizione tra le soluzioni e si sta cercando di impedire a uno sviluppatore di controllo in un'unica soluzione quando sono gated costruzione di un'altra soluzione, allora si dovrebbe essere utilizzando diverse aree di lavoro.

Se si dispone di WorkspaceA per SolutionA e WorkspaceB per SolutionB, quindi le modifiche in sospeso la finestra di dialogo mostra solo le modifiche apportate per l'adeguato spazio di lavoro.

Come dici tu, si sa che si può evitare utilizzando diversi insiemi di modifiche.Questo è come si può "forzare" un sviluppatore di utilizzare due distinti insiemi di modifiche e di evitare la "sviluppatori non sono a conoscenza..." la situazione.

Creare i posti di lavoro per loro e revocare il loro "Creare uno spazio di lavoro" autorizzazione, in modo che loro non possono fare quello che include entrambe le aree.