2015-10-20 6 views
7

Mi sembra che la funzione della dipendenza da snapshot sostituisca completamente quella del trigger di build finito in TeamCity. Qualcuno può spiegare di più l'effetto di questi metodi se provocano un comportamento diverso della catena? Ad esempio, se avessi una catena di build di A-> BQual è la differenza tra dipendenza dello snapshot e trigger di build finito in TeamCity?

La catena si comporta effettivamente in modo diverso tra queste tre configurazioni?

  • Impostazione 1: Singolo finito accumulo grilletto di una in B.
  • Setup 2: singolo snapshot dipendenza di A in B.
  • Impostazione 3: Entrambi finito accumulo grilletto di una e dipendenza snapshot di una definita in B.

Capisco che si possa trattare la dipendenza dello snapshot come operazione "AND" di tutti i depenati, mentre il Trigger di costruzione finito funziona come operazione "OR" tra i depenati. Ma nel contesto di una catena sequenziale, c'è qualche differenza?

Grazie, Scott

risposta

1

Come hai detto tu, non c'è una grande differenza se una configurazione snapshot dipende più altre configurazioni (Z-snapshot a seconda sia X e Y). Ma non ti interessa ...

È vero che nel banale scenario A-> B le Impostazioni 1 .. 3 sono quasi equivalenti. Naturalmente, solo se gli eventi che attivano A e B sono uno-a-uno (ad esempio, sia A che B sono attivati ​​sulla stessa radice VCS oppure utilizzano radici VCS diverse ma vengono attivati ​​manualmente). Se questo è vero, allora la tua catena A-> B è super-banale e potrebbe essere possibile implementarla all'interno di una singola configurazione di build.

Altre differenze sottili che vengono in mente:

  1. il passaggio di parametri a valle della catena.

    • Supponiamo che A e B condividano il parametro "pippo" definito dall'utente. La dipendenza di snapshot A-> B consente di definire %foo% in A e riutilizzarlo in B utilizzando %dep.A.foo%. Questo è davvero comodo perché non devi preoccuparti di mantenere il valore di sincronizzato tra A e B.
    • Supponiamo ora di voler attivare manualmente la catena A-> B con un valore personalizzato di %foo% (tu » ll specificare il valore nella finestra di dialogo "Esegui ...").
    • Poiché TC non può passare il valore fino alla catena (da B a A), è necessario attivare realmente A e specificare il valore personalizzato lì. Quando A termina, attiverà B, che supererà il valore personalizzato. Quello è l'installazione 3.
    • Non è possibile ottenere lo stesso con l'installazione 2, ovvero attivando B con il valore personalizzato. Il valore personalizzato non avrebbe modo di passare a A.
  2. Pianificazione.

    • Supponiamo di avere una risorsa scarsa e B non può essere eseguito per ogni commit. Si finisce con ogni serie di commit VCS "contenenti" (copertura) B. Allo stesso tempo, A non ha problemi di esecuzione per ogni commit.
    • In Setup 1 e 3, se si dispone di un trigger VCS su A, vi ritroverete con
      • una corsa di A per ogni commettere
      • una corsa di B con "aggregato" si impegna (ogni esegue copre più modifiche)
    • in Setup 2, se si dispone di un trigger VCS su B solo, vi ritroverete con commit aggregate in sia a e B. il che può o non può essere quello che vuoi ...
  3. Diverse radici VCS.

    • Se A e B hanno VCS diverse radici, quindi l'installazione 1 (con VCS Trigger su un solo) e alla configurazione 2 (con VCS innescano su B solo) si comporteranno in modo diverso.

In generale, sono d'accordo la natura "pull" delle dipendenze istantanee (Impostazione 2) è molto più attraente. Combinare con il grilletto se necessario (Setup 3).

+0

Grazie per la spiegazione dettagliata. Nella mia situazione, la condivisione di parametri e risorse scarse sono molto rari, quindi userò probabilmente solo la dipendenza da snapshot (setup 2), e userò la combo (setup 3) se c'è un comportamento specifico richiesto con diverse radici VCS. –

+0

Puoi chiarire nel setup 3, A viene eseguito due volte se la dipendenza dello snapshop ha l'opzione "Non eseguire una nuova build se ce n'è una adatta" ** UNCHECKED **? come in ... qualcosa innesca A, quando A completa, _Finitura Build_ si attiva e tenta di mettere B in coda, POI _Snapshot Dependency_ prende il comando e mette A in coda ancora prima che B sia in coda. NON mette un altro A in coda quando ho provato questa configurazione, ma ho pensato in teoria, dovrebbe. TeamCity ha una logica interna per ignorare il passo di accodamento della dipendenza dello snapshot se esiste il trigger di compilazione finito? –

+0

Anche con questa opzione deselezionata, non credo che A debba essere reinserito in coda. Sarebbe terribilmente poco pratico e non riesco a pensare a nessuno che possa desiderare quel comportamento. (Suppongo che tu non voglia questo comportamento, ti stai solo chiedendo cosa faccia questa opzione se non * quella *.) Ciò che questa opzione, credo, è questa: calcio A, lascia B trigger. Entrambi hanno corso una volta. Ora attiva manualmente solo B, senza modifiche al codice dall'ultima build di B. Dovrebbe quel trigger A di nuovo o no? Ecco dove arriva questa opzione. – sferencik

7

Un trigger "Dipendenza istantanea" e "Generazione completata" sono molto diversi. una è fondamentalmente un'operazione "push" mentre l'altra è un'operazione "pull", rispettivamente.

Impostazione 1: Se devo costruire configurazioni A e B dove B ha un trigger "Finito costruire" su A, quindi il comportamento opposto è vero. Attivazione B non avrà alcun effetto sul Un, ma innescando Un sarà effettivamente innescare B una volta terminato.

Setup 2: Se ho la stessa identica configurazione, ma invece B ha una dipendenza istantanea sul A, allora ogni volta che B viene attivato, Un verrà eseguito prima, o almeno di controllo per vedere se è necessario eseguire, prima di eseguire B. SE viene attivato solo A, quindi B non verrà attivato.

Impostazione 3: Impostazione 3 è leggermente diversa perché non dipende solo sul grilletto "Finito Build" o la dipendenza istantanea. ANCHE dipende dal trigger iniziale (VCS, programmato o qualsiasi altra cosa). per esempio, se si dispone di un trigger VCS su A, e B ha sia il grilletto "Finito Costruire" e "istantanea della dipendenza", a A, poi si arriva in modo efficace il comportamento del programma di installazione 1. A sarà attivati ​​in caso di modifiche VCS e B verrà attivato DOPO A (utilizzando la stessa istantanea).In effetti, senza la configurazione dell'istantanea, non è garantito che lo B utilizzi la stessa istantanea di A, che potrebbe essere o meno ciò che si desidera.

Quindi, in generale, quando si desidera un processo di attivazione "da sinistra a destra", si utilizzano ENTRAMBI i trigger di generazione terminati e le dipendenze dello snapshot per garantire la santità del materiale di costruzione.

Se, d'altra parte, si ha il trigger iniziale (VCS o pianificata o qualsiasi altra cosa) di installazione sul B, quindi avere il grilletto "costruire finito" è in qualche modo annullato, perché B sarà sempre essere attivato prima (ma non eseguito), quindi attiverà tutte le sue dipendenze e verrà eseguito automaticamente al termine.

speranza che aiuti. Grazie!

Problemi correlati