Hintergrund. Meine Organisation verwendet Maven, Bamboo und Artifactory, um einen kontinuierlichen Integrationsprozess zu unterstützen. Wir verlassen uns auf den SNAPSHOT-Qualifier von Maven, um den Speicher in Artifactory zu verwalten (alte SNAPSHOT-Builds zu rotieren) und um die teamübergreifende Integration auf dem neuesten Stand zu halten (Maven sucht automatisch nach Updates für SNAPSHOT-Abhängigkeiten bei jedem Build).
Problem. Eine der Herausforderungen, die wir haben, besteht darin, Builds von der Umgebung in die Umgebung richtig zu promoten und gleichzeitig SNAPSHOT zu verwenden. Nehmen wir an, dass ein Tester die Version 1.8.2-SNAPSHOT in eine funktionale Testumgebung implementiert, und zwar in rev 1400 in Subversion. Sagen wir auch, dass es den Funktionstest besteht. Zu dem Zeitpunkt, zu dem sich ein Tester entscheidet, 1.8.2-SNAPSHOT aus Artifactory in die Umgebung für die Leistungstests zu ziehen, könnte ein Entwickler eine Änderung an Subversion vorgenommen haben, so dass die tatsächliche Binärdatei in Artifactory eine andere Version aufweist. Wie stellen wir sicher, dass sich die Revolution bei Verwendung von SNAPSHOT-Builds nicht von uns abwendet?
Einschränkungen. Wir möchten offensichtlich keine verschiedenen Builds unbewusst einsetzen. Wir wollen auch nicht von der Quelle neu aufbauen, da wir die exakte Binärzahl im Leistungstest testen wollen, den wir im Funktionstest getestet haben.
Ansätze, die wir in Betracht gezogen haben. Der Gedanke ist, dass wir die Versionen mit einer vierten Komponente wie 1.8.2.1400 versehen wollen, wobei die vierte Komponente eine Subversion rev ist. (Als Nebenfrage gibt es ein Maven-Plugin oder etwas anderes, das das automatisch macht?) Aber wenn wir das tun, verlieren wir im Wesentlichen die SNAPSHOT-Funktion, da Maven und Artifactory denken, dass dies verschiedene Versionen sind.
Wir verwenden Scrum, so dass wir sehr früh in den Testumgebungen eingesetzt werden (wie Tag zwei oder so). Ich denke nicht, dass es sinnvoll ist, den SNAPSHOT-Qualifier früh im Entwicklungszyklus zu entfernen, da wir die SNAPSHOT-Vorteile wieder verlieren.
Würde es begrüßen zu wissen, wie andere Organisationen dieses Problem lösen.
Um nur auf dieses hier zurückzukommen, wollte ich teilen, was wir tun.
Grundsätzlich stellen wir Snapshot-Builds wie 1.8.2-SNAPSHOT in der Entwicklungsumgebung bereit. Keine anderen Teams müssen diese Builds verwenden, also ist es in Ordnung, -SNAPSHOT auf ihnen zu lassen.
Aber alle Builds, die wir in einer Testumgebung (z. B. Funktionstest, Systemtest) oder anderen Produktionen bereitstellen, müssen die Revision enthalten. z. B. 1.8.2.1400. Wir nennen diese "Quads". Der Grund für das Bestehen auf Quads im Test ist, dass wir Probleme (Features, Bugfixes, etc.) an bestimmte Revisionen anhängen können, so dass die Tester wissen, was getestet werden soll. Für die Produktion ist es nur deshalb so, weil wir genau das gleiche Artefakt einsetzen wollen, das wir getestet haben. Das bedeutet, dass wir ein Quad bereitstellen.
Ich hoffe trotzdem, dass Informationen für jemanden nützlich sind.
Wenn Sie "uniqueVersion" für Snapshot-Builds aktivieren, hat jeder bereitgestellte Snapshot eine eindeutige ID. Sie können dies verwenden, um sicherzustellen, dass Sie die Builds für die korrekte Bereitstellung in Umgebungen bereitstellen.
und, als eine Randnotiz, können Sie das buildnumber-maven-plugin benutzen, um Subversion Buildnumbers zu Artefakten hinzuzufügen.
Anstatt die Build-Nummer der VCS-Revision in die Version des Artefakts einzubetten, betten wir die CI-Build-Nummer in die META-INF/MANIFEST-MF -Datei ein.
Siehe zum Beispiel Verwenden von Hudson-Umgebungsvariablen zum Identifizieren Ihrer Builds . Obwohl der Artikel auf Jenkins / Hudson anwendbar ist, halte ich es für trivial, nach Bamboo zu portieren.
Tags und Links java maven continuous-integration bamboo artifactory