Gebruik je bij het gebruik van Team City snapshot afhankelijkheden de post build-bestanden van de snapshot of gewoon het SVN revisienummer?

Ik heb 2 build-configuraties in één project:

  • Build & Test Code
  • Deploy Code

I want Deploy Code to run only if Build & Test Code built successfully, so I set up a snapshot dependency.

Does a snapshot dependency mean that Deploy Code will check out the same SVN revision as Build & Test Code and then run the NAnt script against that checkout, which will not contain the compiler generated post-build files? Or, will a snapshot dependency on Build & Test Code from Deploy Code mean that the NAnt will run against the post-build, working directory files of Build & Test Code on the build agent?

UPDATE:

It seems if I put a snapshot dependency on Build & Test Code for Deploy Code and I have a build of the latest revision for Build & Test Code, my NAnt script will deploy the post-build files for that build of Build & Test Code.

I would still like to confirm that I understand the concept, as I don't really understand the Team City documentation. I think I should probably make sure Deploy Code runs on the same build agent as Build & Test Code, otherwise I might run into a case where Deploy Code checks out the SVN revision and then just deploys the pre-build code files. Is this correct?

Mijn verwarring is vooral omdat het lijkt dat je een VCS-setup moet hebben voor Deploy Code. Is dat omdat het het nodig heeft om revisienummers te vergelijken met de snapshot-afhankelijkheid?

 7
toegevoegd bewerkt
Bekeken: 1
de bron

2 antwoord

Van het gedeelte Snapshot Dependency van de doco-pagina van de afhankelijke build :

Een momentopname-afhankelijkheid van buildconfiguratie A om te bouwen   configuratie B zorgt ervoor dat elke build van A een "geschikte" build heeft   van B zodat beide builds dezelfde momentopname van bronnen gebruiken (gebruikte bronnen   herzieningen komen overeen met hetzelfde moment).

Dus het idee van een snapshot-afhankelijkheid is dat je een build tegen exact dezelfde codebase kunt uitvoeren als een andere build die er met succes tegenaan loopt.

Als u wilt dat de build van de "implementatiecode" pas wordt uitgevoerd nadat "build and test code" met succes is uitgevoerd, maakt u een momentopname-afhankelijkheid in de tweede build en zorgt u ervoor dat deze is ingesteld op "Gebruik alleen succesvolle builds van de geschikte builds".

Houd in gedachten dat dit niets te maken heeft met artefacten; de tweede build zal eenvoudigweg dezelfde codebase trekken en opnieuw compileren. Als u de artefacten die zijn gemaakt met de eerste build wilt implementeren, moet u in plaats daarvan naar artefact-afhankelijkheden kijken. Dit is precies waar Paul over heeft geschreven in zijn antwoord en is de juiste aanpak.

Wat uw update betreft, klinkt het alsof die post-buildbestanden alleen beschikbaar zijn omdat ze na de eerste build nog steeds op de build-agent staan. Probeer de eerste build uit te voeren en vervolgens "cleaning sources" op de agent uit te voeren en de tweede build uit te voeren. Je zult zien dat de originele compilatie-uitvoer er niet meer is en het zal mislukken. Dit is belangrijk omdat als je meerdere build-agents hebt of enige tijd tussen de twee builds doorbrengt, je simpelweg niet kunt vertrouwen op de uitvoer die niet is opgeslagen omdat artefacten er nog steeds zijn.

En ja, de TeamCity-documentatie is verwarrend :)

7
toegevoegd
de bron
Ik denk dat ik het had moeten vermelden dat ik, volgend op je artikelreeks, een Build-trigger heb in de "implementatiecode" -configuratie in de configuratie "build en testcode". Daarom wordt het getriggerd door een succesvolle build. Het is logisch, in mijn geval, dat de post-buildbestanden er nog steeds zijn, omdat we maar één build-agent hebben, en "deploy-code" zeer binnenkort, zo niet onmiddellijk, na "build-testcode" moet lopen. Ik denk dat ik hoe dan ook zal overschakelen naar het opslaan van artefacten, want dat lijkt de betere praktijk te zijn.
toegevoegd de auteur JustinP8, de bron
Is het geschikt voor pakketten? Ik heb veel pakketten. De meeste van mijn projecten gebruiken ze. Kan ik Build maken dat alleen alle pakketten verzamelt en het vervolgens als Snapshot Dependency voor alle andere builds gebruikt?
toegevoegd de auteur dariol, de bron

Ik heb een vergelijkbare opstelling in TeamCity, behalve dat ik MSBuild niet NAnt gebruik, maar ik gebruik hetzelfde proces voor het maken van 2 stappen en als ik uitleg hoe ik het heb geconfigureerd, zal het hopelijk helpen om te begrijpen wat je moet doen.

Dus in mijn opstelling haalt Build 1 de code uit bronbesturing, compileert deze en voert de eenheidstests uit. Vervolgens worden alle vereiste bestanden voor implementatie als artefacten gepubliceerd.

Build 2 heeft een momentopname en een artefactafhankelijkheid van Build 1 en dit betekent dat er geen code wordt getrokken, het neemt gewoon de artefacten uit Build 1 en implementeert ze.

In de praktijk betekent dit dat ik Build 2 kan activeren en dat er een of twee dingen gebeuren. Als Build 1 up-to-date is, worden de artefacten van de laatste succesvolle build van Build 1 eenvoudig geïmplementeerd. Als Build 1 echter niet up-to-date is, wordt Team 1 automatisch gegenereerd en wordt Build 2 daarna rechtstreeks uitgevoerd met behulp van de artefacten van die versie. bouwen.

6
toegevoegd
de bron
Ik heb dit soort instellingen eerder gezien, maar ik denk niet dat de afhankelijkheid van artefacten noodzakelijk is. Ik heb nu een proof of concept dat een NAnt-kopieerscript uitvoert met een afhankelijkheid van de build-/testconfiguratie. Het lijkt goed te werken tot nu toe, ik weet alleen niet zeker of er een geval is waarin de door de build gegenereerde .dll's niet worden opgenomen. Ik denk dat ik gewoon in de war raak waarom een ​​VCS-configuratie nodig is voor de build als het niets uitzoekt, alleen het gebruik van de post-build-bestanden van de afhankelijkheid. Ik vermoed dat het alleen maar is om revisienummers te vergelijken.
toegevoegd de auteur JustinP8, de bron