Qual è la differenza tra dipendenza dello snapshot e trigger di build finito in TeamCity?

Question

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-> B

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

Answer 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).

Answer 2

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!