[Maven2] Deploy auf Artifactory mit LDAP Authentication

[pocketom]

Ich nutze das LDAP Modul in Artifactory. Nun kann sich jeder Nutzer in unserer AD-Domäne mit seinen gewohnten Zugangsdaten am Webfrontend von Artifactory einloggen, die Pflege eines seperaten Nutzerkreises entfällt. Sinn und Zweck der Aktion war/ist es jedoch den Author beim deployen korrekt zu erfassen. Dies will mir einfach nicht gelingen. Nicht ohne den Author zumindest in der POM bzw. settings.xml fest einzutragen:

[xml]
<server>
<id>${server-id}</id>
<username>myname</username>
<password>\{DESede\}Klso02Hasona7x5mauw1==</password>
</server>
[/xml]

Aber jetzt muss natürlich wieder jeder stets aufpassen das er sich vor dem Deploy korrekt in der POM einträgt. Vergisst man's, so deployed man schnell unter einem falschen Namen. Eine kleine Verbesserung bringt es sich vor dem SVN checkin wieder aus der POM zu entfernen, so stolpert der Nächste dann automatisch drüber. Erfordert aber auch immer dran zu denken. Nix für uns faule Informatiker... ^^

Das muss doch irgendwie auch anders gehen, sprich halt automatisch ohne fest im File einzutragen oder? Schliesslich ist man ja bereits auf der Entwicklermaschine mit seiner AD-Kennung angemeldet.

 

[maki]

Wahrscheinlich in der [c]~/.m2/settings.xml[/c].

 

[pocketom]

Das funktioniert, sofern in allen POMs die selbe Server-ID verwendet wird, dies müsste aber mit einer globalen Property möglich sein (etwas unglücklich das Artifactory "server-id" anstatt ein eindeutigeres "artifactory-server-id" verwendet o.Ä.).
Jedoch haben wir immer einige Externe da und allgemein eine hohe Fluktuation, gerade bei den indischen Kollegen, weswegen ich die LDAP Config ursprünglich gemacht habe. Nun jedes Mal jedem zu erklären woher er sein Keyphrase bekommt und wie und wo er das einträgt... Ich hatte gehofft das würde mit der LDAP Anbindung halt ganz entfallen, jeder muss ohnehin einmal in AD angelegt werden. Ein Maven Modul das beim releasen nach User/PW frägt gibts wohl nicht oder?

 

[maki]

Du könntest das Problem an sich vermeiden wenn nicht jeder Benutzer direkt in die Artifaktory deployed... lass das zB. einen Hudson (CI Server) machen.
SNAPSHOTS sollten sowieso nicht deployed werden(wär ja quatsch), und wenn offizielle Releases nur von einer Instanz (zB. Hudson oder ein best. Entwickler) in die Artifaktory deployed werden, stellt sich dien Problem gar nicht mehr, oder?

 

[pocketom]

Hmm, ich glaube das könnte hier etwas schwierig werden. Die miesten Entwickler pflegen einen eher agilen Stil und sind in kleinen unabhängigen Teams organisiert. Wir wollen deshalb versuchen Overhead wo immer nur möglich zu vermeiden. Wichtig wäre dennoch dass der Author/Publisher des Artefakts jedes Mal erfasst wird. Wäre das bei einem Hudson Server gewährleistet oder wäre der Author jedesmal ein Standardbenutzer?

 

[maki]

Agil ist gut, heisst aber nicht dass jeder einfach so einen Release erstellen kann bzw. sollte.

Der Author/Publisher einers Releases ist immer der CI Server
Manche CI Server wie Continuum haben dafür einen eigenen Button.
Die Änderungen am Code sind ja im SCM dokumentiert, deswegen verstehe ich nicht warum es wichtig sein sollte den "Author" einen Releases festzuhalten... wichtig ist doch nur der Author von jeweiligen Änderungen.
Sieh dir mal an wie die meisten Agilen Opensource Projekte organisiert sind, da macht meistens auch ein CI Server Releases (Nightly Builds, echte Releases, etc. pp.)

 

[pocketom]

Danke für den Tip! Ich werd mich mal mit der Thematik befassen. Continious Integration haben wir bis jetzt nicht. Wir sind gerade dabei überhaupt mal auf breiter Front mit Unit Tests zu beginnen (ich predige da schon länger hin...). Das ist nicht so einfach da wir halt auch eine Vielzahl von Technologien haben (.NET, Java, Delphi, TCL,......).

 

[maki]

Ohne Unittests & Ci Server ist es voll daneben von Agilen Projekten zu sprechen
Agil heisst auch nicht chaotisch & ohne Planung & ohne Anforderungen, wird auch oft verwechselt.

 

[pocketom]

Jaaaein ;-)

Wir "steuern" unsere Projekte mit SCRUM, das hat bis jetzt schon vieles geändert (wir scrummen halt auch erst seit 3 Monaten). Deshalb ist es auch keinesfalls chaotisch. Planung und Anforderungen finden immer einleitend zum Planingpoker statt, Kontrolle und Bewertung der Zielerreichung im Retrospective Meeting. Aber natürlich müssen wir uns noch weiter in diese Richtung bewegen...! Grad die Productowner aus den einzelnen Geschäftsbereichen tun sich manchmal noch ein bischen schwer weil sie plötzlich natürlich viel mehr Verantwortung tragen müssen als dies bisher der Fall war ("Ich verkünde zwischen Tür und Angel meine Wünsche und die IT wird da schon irgendwas für mich aushecken"). Die Priorisierung läuft zumindest schon deutlich besser in einigen Bereichen, bzw. fragen sich die Leute jetzt schon vorher "Brauch ich Feature XYZ wirklich oder gibt es was noch Wichtigeres". Aber auch die Developer verschätzen sich teilweise noch erheblich

 

[maki]

Wollte mit diesem Satz

Agil heisst auch nicht chaotisch & ohne Planung & ohne Anforderungen, wird auch oft verwechselt.

keinesfalls andeuten dass es bei euch so läuft, sind aber ein paar Vorurteile dich ich oft erlebt habe.

SCRUM ist gut, aber ein bisschen XP gehört auch schon dazu, denn bei SCRUM geht es "nur" um die Projektorganisation.
XP ist von Entwicklern für Entwickler, aber eben etwas extremes, Unittests allgemein und besonders TDD gehört zu XP.
Klar sind Unittests auch Code der gewartet, verwaltet und verbessert werden muss, dafür hast du aber weniger Produktivcode und ausserdem die Sicherheit, dass dieser Produktivcode auch funktioniert, selbst nach Änderungen wie zB. Refactoring oder Erweiterungen, das gibt einerseits ein Gefühl von Sicherheit, hilft auch bessere Schätzungen abzugeben, da man nicht mehr Raten muss sondern testen kann und dadurch einen besseren Eindruck vom Aufwand bekommt.

 

[pocketom]

Hmm, wir haben jetzt ein generelles Problem mit Artifactory. Es wurde im Artifactory eine Gruppe erstellt in der alle AD-User enthalten sind die lesend zugreifen dürfen. Nun bietet Artifactory die Möglichkeit den [c]<server>[/c] block gleich fix und fertig für jeden angemeldeten Benutzer zu generieren. Das funktioniert aber leider nicht bis zum Ende...

Ich habe also diesen block (s.o.) in die ~/.m2/settings.xml eingetragen. Beim Ausführen von 'mvn foo:bar' möchte Maven z.B. ein Plugin oder eine Dependecy herunterladen - und scheitert mit einem Authorization Error. Die [c]settings-security.xml[/c] würde fehlen. Also habe ich das File angelegt und mit [c]mvn -emp myMasterPW[/c] ein Masterpasswort erzeugt und eingetragen. Es kommt jedoch immer noch 'Authorization failed'. Nun habe ich also auch noch das Passwort selbst mit [c]mvn -ep myUserPW[/c] verschlüsselt und im Server-Block in der ~/.m2/settings.xml überschrieben. Klappt aber auch nicht da dieses wohl von Artifatory nicht akzeptiert wird.

Mal wieder am Ende mit der Weisheit

:-(