Wir haben einen Job bei Jenkins ( Production ), um jede Nacht ein Ergebnis zu erstellen. Wir haben einen anderen Job ( ProductionPush ), der das Ergebnis über ein proprietäres Protokoll am nächsten Tag an die Produktionsmaschinen weiterleitet. Dies liegt daran, dass einige Produktionsmaschinen nur während bestimmter Stunden am Tag verfügbar sind (es gibt uns auch die Möglichkeit, Build Breaks in letzter Minute zu beheben). ProductionPush benötigt Zugriff auf die über den Job Production erstellte Lieferung (benötigt also Zugriff auf denselben Arbeitsbereich). Wir haben mehrere Knoten und gleichzeitige Builds (und damit unvorhersehbare Arbeitsbereiche) und ziehen es vor, die Jobs nicht an einen festen Knoten / Arbeitsbereich zu binden, da die Ressourcen begrenzt sind.
So stellen Sie sicher, dass beide Jobs den gleichen Arbeitsbereich verwenden und sicherstellen, dass ProductionPush zu einem festen Zeitpunkt am nächsten Tag ausgeführt wird, wenn Production erfolgreich ist - ohne dass beide Jobs vom selben Knoten ausgehen / Arbeitsplatz? Ich weiß, dass das parametrisierte Trigger-Plugin mit einigen davon helfen könnte, aber es scheint nicht so zu sein haben Zeitverzögerung Fähigkeit und 12 Stunden scheint zu lang für eine ruhige Zeit.
Ist das Teilen des Arbeitsbereichs eine schlechte Idee?
Antwort 2: Ja, das Teilen des Arbeitsbereichs ist eine schlechte Idee. Es besteht die Möglichkeit von Dateisperren. Es gibt das Problem, dass der Arbeitsbereich gelöscht wird. Tu es einfach nicht ...
Antwort 1: Sie müssen die Artefakte des Builds archivieren . Auf diese Weise werden die Artefakte für einen bestimmten Build (nach Build-Nummer) immer verfügbar sein, unabhängig davon, ob ein anderer Build ausgeführt wird oder nicht, oder welchen Status die Arbeitsbereiche in
haben*.* /path/to/file_version*.zip **/file_version*.zip http://JENKINS_URL/job/JOB_NAME/lastSuccessfulBuild/artifact/ und dann den Namen des Artefakts. Ich habe ausführlich erklärt, wie Sie hier auf frühere Artefakte von einem anderen deploy Job (in Ihrem Beispiel ProductionPush ) zugreifen können:
Wie eine bestimmte Build-Nummer von einem anderen Job in Jenkins fördern?
Wenn Ihre Anforderungen die neueste Version immer in Production bereitstellen sollen, können Sie die Konfiguration von Aktion im obigen Link überspringen. Befolgen Sie einfach die Schritte zur Konfiguration des deploy Jobs. Wenn der Job deploy einmal ausgeführt wird, konfigurieren Sie einfach die Parameter Build periodic . Alternativ können Sie einen weiteren Job haben, der den Job deploy basierend auf den von Ihnen gewünschten Bedingungen auslöst.
Wenn Ihr Standard-Selektor wie oben im Link angegeben auf Letzter erfolgreicher Build gesetzt ist, wird der neueste Build in beiden Fällen nach Production
Nicht sicher Archivartefakte ist wirklich eine gute Idee. Ein Staging-Repository ist möglicherweise besser, da es funktionsübergreifenden Teams ermöglicht, Artefakte in verschiedenen Builds zu teilen, wenn dies erforderlich ist, indem Sie die Maven-Datei settings.xml optimieren.
Sie möchten wirklich ein bereitstellbares (ear / war) als die Sache, die gebaut, getestet und dann zur Produktion befördert wird, sobald das Vertrauen mit dem Build hoch ist.
Verwenden Sie eine Build-Nummer auf Ihrem Deployable (major.minor.buildnumber). Dies ist die Sache, die Sie zur Produktion fördern, vorausgesetzt, Ihre Tests sind zuverlässig. Verwenden Sie keinen Bindestrich, um Moll mit der Build-Nummer zu trennen, da dies Maven zwingt, einen lexikalischen Vergleich durchzuführen ... ein Dezimalpunkt wird einen numerischen Vergleich erzwingen, der Ihnen weit weniger Kopfschmerzen bereitet.
Sie haben auch Ihre Zielplattform nicht erwähnt, aber mit dem Maven APT / RPM-Plugin, um eine APT / RPM zu einem APT / YUM-Repo zu schieben, das für eine Produktionskiste verfügbar ist (nach erfolgreichem Test!) wäre eine gute Sache passen, wie Industriestandards?
Tags und Links triggers jenkins workspace continuous-delivery