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