Hi,
Ich würde gerne nochmal an das Ticket erinnern. Wenn wir dafür ein Workaround finden können wir den v0.1 Milestone abschließen.
vg Tarek
Hi,
Ich würde gerne nochmal an das Ticket erinnern. Wenn wir dafür ein Workaround finden können wir den v0.1 Milestone abschließen.
Ich habe mir da jetzt gerade auf der Zugfahrt von Oldenburg nach Emden ein Workaround ausgedacht der denke ich einfach zu verstehen ist und dennoch die nötige Sicherheit gibt, das nicht aus versehenen ungewollte Änderungen auf die Server deployt werden.
ausgehend vom puppet repo würde ich folgendes umsetzen. Wenn niemand was dagegen hat.
Entwickelt wird im master ganz normal nach dem gitlab workflow. Wenn es fertige Änderungen gibt z.b. Milestone ist erreicht oder kleinere Features sind vollständig können diese fertigen Änderungen via git merge oder cherry-pick in Produktion gezogen werden. gibt es einen aktiven zustand der puppet-Master ausgerollen soll, so würde ich vorschlagen das die zu den o.g. zustand gehörende commit-ID entsprechend mit einem tag versehen wird. Tag style würde ich folgende Notation vorschlagen vX.X z.B. v0.1 <-- das würde dem Milestone entsprechen. gibt es kleinere änderungen die außerhalb des Milestons in aktion gehen sollen so würde ich diese einfach als Mijor version an einen neunen tag hägen z.B. v0.1.1 Das v0.1 sagt dann aus, auf welchen Milestone der Puppetmaster gerade ist und das folgende also .1 nach 0.1 zeigt die nachträgliche Änderung die auf dem Milestone setzt.
Wird ein neuer Tag gesetzt und in den Upstream gepusht, so kann irgendjemand der den nötigen rechte hat auf dem puppetmaster Server einfach ein git pull machen und anschließend mit git checkout die nächst neuerer Version auschecken. Somit sollte die Gefahr stark minimiert werden jemand aus verseht via puppet alle Server auf einmal kaputt macht.
Schönen Gruß :) Tarek
Ich sehe hier im Tagging keinen Sinn, außer dass man dem Kind einen Namen gibt.
Ich denke es sollte nicht zu kompliziert werden, Änderungen vorzunehmen. Die Perspektive eigene Ideen aufgrund von Verwaltungsakten nicht umsetzen zu können, ist für mich einer der stärksten Gründe nicht an Projekten zu arbeiten.
Letzlich geht es doch nur darum die Wahrscheinlichkeit für ein folgenreiches Versehen möglichst gering zu halten. Wer Zugriff auf den puppet-Master hat, hat ohnehin die Macht alles kaputt zu machen. Dementsprechend vorsichtig sollte man in bestimmten Bereichen sein und Änderungen lieber in einer eigens dazu eingerichteten Umgebung testen. Ein komplizierter git-release Zyklus schützt da wenig.
On 03/13/16 23:51, Simon Kurka via Dev wrote:
Ich sehe hier im Tagging keinen Sinn, außer dass man dem Kind einen Namen gibt.
Genau das ist eigentlich die Idee somit kann man in der commit history gut nachvollziehen wann welchen Millionstes bearbeitet wurden und wie. Man hat somit auch eine einfache Möglichkeit zwischen den tags mit git diff alle Änderungen genau zu sehnen und kann somit sehr einfach reviewen.
Ich denke es sollte nicht zu kompliziert werden, Änderungen vorzunehmen. Die Perspektive eigene Ideen aufgrund von Verwaltungsakten nicht umsetzen zu können, ist für mich einer der stärksten Gründe nicht an Projekten zu arbeiten.
Da stimme ich dir zu ich bin auch kein großer freund von Verwaltung, allerdings dient diese Struktur dazu einfacher und übersichtlicher im Team zu entwickeln da somit z.B. alle Team-mitglieder die aktuell entwickeln wissen wie die anderen Team Partner entwickeln. Sowelche Strukturen sind Ansich als Einzelner Entwickler Erstmal gewöhnungsbedürftig allerdings ist das im Team sehr effectiv.
Letzlich geht es doch nur darum die Wahrscheinlichkeit für ein folgenreiches Versehen möglichst gering zu halten. Wer Zugriff auf den puppet-Master hat, hat ohnehin die Macht alles kaputt zu machen. Dementsprechend vorsichtig sollte man in bestimmten Bereichen sein und Änderungen lieber in einer eigens dazu eingerichteten Umgebung testen. Ein komplizierter git-release Zyklus schützt da wenig.
Das ist so nur teilweise korrekt. In erster Linie geht es darum eine Team Arbeit effectiver zu gestalten. Ein weiterer Hintergrund ist den einstig in die puppet Entwicklung zu vereinfachen da es eine entsprechende Struktur gibt die dokumentiert ist und die alle Mitentwickler kennen und der Letzte wichtige Hauptpunkt ist natürlich auch zu verhindern das größere Schäden via puppet erzeugt werden. Ein testen in einer eigenen Umgebung ist da nicht ausgeschlossen und soll auch gemacht werden bevor in production gemerge oder co wird.
vg :) Tarek
Am Montag, 14. März 2016, 00:15:05 CET schrieb Jan-Tarek Butt via Dev:
On 03/13/16 23:51, Simon Kurka via Dev wrote:
Hi,
wenn wir einen Milestone abschließen ist es sicherlich sinnvoll einen Tag zu setzen. Es wird aber öfter mal vorkommen, dass wir kleinste Änderungen schnell in production bringen müssen. Beispielsweise das hinzufügen eines neuen Benutzers. Ich denke da lohnt Tagging wirklich nicht.
Letzendlich kann man mit Puppet schnell Dinge kaputt machen. Man kann sie aber auch genauso schnell wieder heile machen indem man seine Änderungen einfach umkehrt. Der einzige wirklich problematische Bereich ist der Bereich der primären Netzwerkkonfiguration (eth0). Aber da sind vielleicht auch alle Beteiligten genug sensibilisiert Änderungen in diesem Bereich nur im Rahmen von Milestones vorzunehmen.
Darum würde ich den Entwicklungsprozess wie von Tarek zusammengefasst vorschlagen mit der Bitte von Simon, dass einfache Konfidurationsänderungen auch ohne Tag eingespielt werden können. Also:
* (done) Unterscheidung in master und production Branch im Git * (done) Unterscheidung in master und production environment * (TODO) Trennung von Production (puppet.ffnw.de) Supernode und Entwicklungssupernode (z.B. testpuppet.ffnw.de) * (TODO) Dokumentation des Prozesses
Viele Grüße Clemens
Hi,
wenn wir einen Milestone abschließen ist es sicherlich sinnvoll einen Tag zu setzen. Es wird aber öfter mal vorkommen, dass wir kleinste Änderungen schnell in production bringen müssen. Beispielsweise das hinzufügen eines neuen Benutzers. Ich denke da lohnt Tagging wirklich nicht.
Letzendlich kann man mit Puppet schnell Dinge kaputt machen. Man kann sie aber auch genauso schnell wieder heile machen indem man seine Änderungen einfach umkehrt. Der einzige wirklich problematische Bereich ist der Bereich der primären Netzwerkkonfiguration (eth0). Aber da sind vielleicht auch alle Beteiligten genug sensibilisiert Änderungen in diesem Bereich nur im Rahmen von Milestones vorzunehmen.
Darum würde ich den Entwicklungsprozess wie von Tarek zusammengefasst vorschlagen mit der Bitte von Simon, dass einfache Konfidurationsänderungen auch ohne Tag eingespielt werden können. Also:
- (done) Unterscheidung in master und production Branch im Git
- (done) Unterscheidung in master und production environment
- (TODO) Trennung von Production (puppet.ffnw.de) Supernode und
Entwicklungssupernode (z.B. testpuppet.ffnw.de)
- (TODO) Dokumentation des Prozesses
Ok super :) ich halte das dann mal so im Wiki fest und richte ein testpuppet.ffnw.de ein. :)
vg Tarek
-
Clemens John -
Jan-Tarek Butt -
Simon Kurka