Ich suche Best Practice Richtlinien für Versionsverwaltung, denn in der Firma gibt es Kollegen, insbesondere einige die nicht programmieren können, die meinen da gehören nur freigegebene Versionen hin - was bedeuten würde das ungefähr einmal alle 3 Jahre Checkin gemacht würde, von um 3 Programmierern, die am gleichen Sourcecode arbeiten. Ich mache aber ein Checkin täglich wenn ich an einem Tag stundenlang programmiert habe, damit ich nicht hunderte lokale Kopien verwalten muss und auch per Rechtsklick verschiedene Versionen von Dateien vergleichen kann. Das bedeutet natürlich auch beim Mergen verschiedener Zweige einige Zwischenstände, mit denen man kein Build machen kann, aus denen also keine ausführbare Software gemacht werden kann. Aber das beeinträchtigt ja nicht die lauffähigen Versionen, die zudem in dem Log klar beschrieben sind und da hier nur die Entwickler selbst die Software machen, gibt es keine Anforderung wie ein Nightly Build, so das es da kein Problem gibt. Bisher finde ich zu dem Thema praktisch nichts, keine Quellen die erläutern würden das Versionsverwaltung mehr als nur das Ablegen von freigegebenen Versionen ist, mehr als nur Archivierung. Wo findet man sowas?
Kommt ja auch auf den persönlichen Geschmack an. Wenn ich dran denke/nicht zu faul bin und es sinn macht, geht bald jede Zeile in ein commit auf. Grade wenn man mit mindestens zu zweit an einer Sache arbeitet und bestehen Code ändert, ist man dafür schnell dankbar.
Bei und werden per TFS sowohl die Anforderungen als auch die Tätigkeiten/Arbeitsaufwände verwaltet. Zu den meisten Aufgabe gehört Code oder Doku der eingecheckt wird und dann mit der jeweiligen Aufgabe verlinkt wird. Sprich, man checkt deutlich öfter als 5 mal am Tag ein.
Ohne da jetzt auf Literatur verweisen zu können, ich hab das in verschiedenen Firmen und unterschiedlichen Projekten überall gleich kennengelernt (ich hab aber praktisch nur git Erfahrung): Machst du eine kleine Änderung, nen kleinen Bugfix oder so, dann machst du das, committest das und pusht das. Machst du größere Änderungen branchst du vorher, commitest jedes "Häppchen" das du gesonder betrachten und einzeln fertig stellen kannst. Du Mergest dabei regelmässig den Aktuellen Funktionierenden Stand in dein Entwicklungszweig. Bist du Fertig Mergst du zurück. Wenn möglich Baut das Buildsystem alles was du pusht, und meldet sich bei dir wenn's kaputt geht. Um Releases zu Markieren gibt es Tags. Schreibt man gute Commit-Messages kann man seine Changelog zum Release einfach auf der commit-log generieren. Ob das das Gelbste vom ei ist oder nicht, da kann man gerne, lange und Ausgiebig drüber streiten. Sicher ist aber: einzelne Änderungen gehören einzeln verpackt unter Versionskontrolle. Wenn du eher sowas wie ein Leitfaden sucht les dich ggf. mal in git flow ein. Das ist für die meisten zwar Overkill, aber da kann man einfach das rausstreichen was man nicht braucht, das was über bleibst ist sicherlich nicht schlecht.
Für git gibt es einen sehr guten Guide von Atlassian: https://www.atlassian.com/git/tutorials/comparing-workflows Es wird besonders herausgestellt, dass Versionsmanagement mehr ist als regelmäßige Sicherungskopien. Es gibt noch ein ähnliches Dokument für SVN, aber das finde ich gerade nicht.
Rene H. schrieb: > Welches Repo? Git? Svn? Das ist nebensächlich. Man braucht es beipielsweise wenn ein Fehler X bei auftritt, um nachzusehen ob es bei der ältesten Version auftrat und wenn nicht, durch Intervallhalbierung effizient festzustellen zwischen welchen zwei Versionen der Fehler hinein kam. Durch Vergleichen kann man die Ursache meist schnell einkreisen und lokalisieren sowie beseitigen. Das funktioniert natürlich nur wenn man mindestens einmal täglich ein Checkin macht und nicht nur alle 3 Jahre. Das ist aber nicht-Programmierern nur schwer vermittelbar.
Erwin M. schrieb: > und da hier nur die Entwickler selbst die Software machen, gibt es keine > Anforderung wie ein Nightly Build Was hat das eine mit dem anderen zu tun? Nightly Builds sind generell sinnvoll. Auch gute Leute machen manchmal Fehler. "Oh, ich muss in einer Viertelstunde meine Tochter vom Kindergarten abholen. Naja dann committe ich jetzt schnell noch, zum Testen ist dann keine Zeit mehr heute aber wird schon passen." Und prompt auf die Schnauze gefallen.
:
Bearbeitet durch User
Erwin M. schrieb: > Ich suche Best Practice Richtlinien für Versionsverwaltung, denn in der > Firma gibt es Kollegen, insbesondere einige die nicht programmieren > können, die meinen da gehören nur freigegebene Versionen hin - was > bedeuten würde das ungefähr einmal alle 3 Jahre Checkin gemacht würde, > von um 3 Programmierern, die am gleichen Sourcecode arbeiten. Also, es wurde im thread schon einiges zu besseren Verfahrensweisen gesagt, aber nur mal interessehalber, da sich das oben geschilderte nach dem größtmöglichen Unfall anhört: Wie verwalten die Leute momentan ihre Entwicklung "lokal"? Jeder mit seinem eigenen Repo oder womöglich gar nicht? Und wie und wann wird gemerged? Nach 3 Jahren, nachdem sich der Code komplett auseinander entwickelt hat? Gruselige Vorstellung.
Erwin M. schrieb: > Das bedeutet natürlich auch beim Mergen verschiedener Zweige einige > Zwischenstände, mit denen man kein Build machen kann, aus denen also > keine ausführbare Software gemacht werden kann. Aber das beeinträchtigt > ja nicht die lauffähigen Versionen, die zudem in dem Log klar > beschrieben sind und da hier nur die Entwickler selbst die Software > machen, gibt es keine Anforderung wie ein Nightly Build, so das es da > kein Problem gibt. Oder, man hält sich einen main branch der immer kompilieren muss und alle automatischen tests besteht und einen Integrationsbranch, wo die Anforderungen ggf. etwas entspannter eingestellt sind, aber der regelmäßig in main einfließt.
Erwin M. schrieb: > Ich mache aber ein Checkin täglich wenn ich an einem Tag stundenlang > programmiert habe, damit ich nicht hunderte lokale Kopien verwalten muss > und auch per Rechtsklick verschiedene Versionen von Dateien vergleichen > kann Bei uns muss jede neue Funktion bzw. jeder Bugfix einen einzelnen, atomaren Commit besitzen. Dazu direkter Verweis auf das Incident-Management wo alles zentral geloggt ist. Im Trunk muss IMMER eine lauffähige Funktion sein. Wenn das ein Entwickler verkackt, wird er geteert und gesteinigt. Das ist schon der Grund warum alle einen Brach für ihre aktuelle Entwicklungsarbeit nutzen. Die Testabteilung bezieht ihre Testresultate immer auf die jeweilige GIT- bzw. SVN-Revision.
Vielleicht hilft da ja ein Blick in diese Zeitschrift zum Thema GIT, gerade rausgekommen: http://www.webundmobile.de/update/internet/inhalt-aktuellen-ausgabe-1062941.html Mit 15 Euro leider auch sehr teuer...
physiker schrieb: > > Also, es wurde im thread schon einiges zu besseren Verfahrensweisen > gesagt, aber nur mal interessehalber, da sich das oben geschilderte nach > dem größtmöglichen Unfall anhört: Wie verwalten die Leute momentan ihre > Entwicklung "lokal"? Jeder mit seinem eigenen Repo oder womöglich gar > nicht? Und wie und wann wird gemerged? Nach 3 Jahren, nachdem sich der > Code komplett auseinander entwickelt hat? Gruselige Vorstellung. Ja, aber für Leute die keine Ahnung davon haben ist das nicht gruselig sondern irgendwie normal.
physiker schrieb: > Erwin M. schrieb: >> Das bedeutet natürlich auch beim Mergen verschiedener Zweige einige >> Zwischenstände, mit denen man kein Build machen kann, aus denen also >> keine ausführbare Software gemacht werden kann. Aber das beeinträchtigt >> ja nicht die lauffähigen Versionen, die zudem in dem Log klar >> beschrieben sind und da hier nur die Entwickler selbst die Software >> machen, gibt es keine Anforderung wie ein Nightly Build, so das es da >> kein Problem gibt. > > Oder, man hält sich einen main branch der immer kompilieren muss und > alle automatischen tests besteht und einen Integrationsbranch, wo die > Anforderungen ggf. etwas entspannter eingestellt sind, aber der > regelmäßig in main einfließt. Das geht nicht, z. B. wenn im Branch zusächliche Inklude-Dateien sind, eine ganz andere Ablaufsteuerung verwendet wird oder inkonsistente Variablendeklarationen verwendet werden; da kann nicht mal etwas einfließen sondern da geht, ohne großen Aufwand, nur alles oder nichts zu mergen. Da hat man dann die Wahl den Branch auf dem letzten guten Stand zu lassen und in Main einzuarbeiten oder umgekehrt plus alles aus dem Branch in Main zu übernehmen. Ich hatte das erste genommen, weil ich in der Zeit der einzige war, der an beiden Zweigen arbeitete und das hat gut funktioniert, aus dem Build vom Main alle der über 300 Warnmeldungen beseitigt.
:
Bearbeitet durch User
Für kleine Projekte (mit einer Handvoll Leute; geringer Compilezeit; schnellen Durchlauf der automatischen Test) ist es imho sinnvoll: -- Ein Main branch, der immer kompilierbar ist und wo alle Tests durchlaufen müssen. -- Auch hier wird die Main niemals direkt geändert (weil fehleranfällig) sondern aus einen Seitenbranch werden Änderungen konfliktfrei "propagiert" nachdem im Seitenbranch bereits die Integration (aus der Main) durchgeführt wurde (kompiliert, Tests laufen durch). -- Jeder Projektbeteiligte hat einen privaten Seitenbranch (in den der eine vielleicht alle 10min eincheckt und der andere alle Woche einmal). Ob und wann ein Abgleich mit der Main vorgenommen wird, das kann sehr speziell sein. Ein VCS kann einiges, aber nicht solche Absprachen ersetzen (die in einem kleinen Team quasi auf Zuruf gehen sollten).
:
Bearbeitet durch User
Erwin M. schrieb: > Ich suche Best Practice Richtlinien für Versionsverwaltung Wenn man es Versionsverwaltung nennt, verwaltet es nur Versionen, also Software mit einer anderen Versionsnummer. Darin befinden sich tunlichst Sourcen UND Compilerinstallation UND ausgelieferte EXE, denn die Theorie, man könne jederzeit aus dem Sourcenstand eine Version z.B. zum Debuggen wiederhersellen, ist Humbug, wenn sich zwischendrin die Compilerversion ändert. Weil die Datenmengen recht gross sind, sollte man das nur für ausgelieferte Versionen machen, die jeweils eine andere Versionsnummer tragen und durch alle automatisierten Test (ISO9001, stelle sicher daß ein schon gefixter Fehler nicht mehr auftaucht) durchgelaufen ist. Weil das nicht bei jedem Build so ist, wird zwar vor dem Build eine Versionsnummer eingetragen, aber die gebuildete Version erst NACH erfolgreichem Build (auf allen Plattformen) und Tests mit dieser Versionsnummer eingecheckt. Auf die Art bekommt man auch wirklich mal eine Version 2.0 und nicht 2.0.0.5765 als erste ausgelieferte Fassung, vor allem kann schon vor dem Build die Doku mit den entsprechenden Versionsnummern versehen werden. Was du meinst, ist nicht unbedingt die Versionsverwaltung, sondern bloss eine Sourcenverwaltung ggf. uncompilierter und ungetester Programme als Archiv und damit man Änderungen nachvollziehen kann und die mit anderen sharen kann. Die nervt um so mehr, um so mehr Arbeit es für den Programmierer ist, darin einzuchecken, es sollte also KEINERLEI Arbeit sein einzuchecken (auschecken kommt eher selten vor, das darf einen Handgriff erfordern). Es lohnt sich, wenn der Rechner einfach automatisch jeden Tag oder gar bei jedem speichern die lokalen Sourcen archiviert so dass man jederzeit später auf jeden alten Stand zugreifen kann, ohne eine Versionsnummer vergeben haben zu müssen, also nach Timestamp. Im einfachsten Fall tut es ein zentrales Serververzeichnis, ansonsten ein Git-Zugriff in Eclipse oder Microsoft TFS, natürlich kann man auch die ausgelieferten Versionen mit demselben Tool verwalten, sollte aber eine andere Datenbank verwenden. Vorsicht vor CVS, das kommt mit Gross-/Kleinschreibung nicht zurecht.
Schon ein paar Jahre alt, noch immer hörenswert: http://cre.fm/cre130-verteilte-versionskontrollsysteme
Erwin M. schrieb: > physiker schrieb: >> >> Also, es wurde im thread schon einiges zu besseren Verfahrensweisen >> gesagt, aber nur mal interessehalber, da sich das oben geschilderte nach >> dem größtmöglichen Unfall anhört: Wie verwalten die Leute momentan ihre >> Entwicklung "lokal"? Jeder mit seinem eigenen Repo oder womöglich gar >> nicht? Und wie und wann wird gemerged? Nach 3 Jahren, nachdem sich der >> Code komplett auseinander entwickelt hat? Gruselige Vorstellung. > > Ja, aber für Leute die keine Ahnung davon haben ist das nicht gruselig > sondern irgendwie normal. Könnte es sein, dass das eigentliche Problem an einer ganz anderen Stelle liegt? Wenn es keinen SW-Projektleiter gibt, der Termine vorgibt wann was fertig zu sein hat (fertig = getestet und im Release integriert), dann hat man ein Problem. In einer vernünftig geführten Abteilung kann es nicht passieren, dass jemand jahrelang vor sich hinfrickelt und seinen Code in der ganzen Zeit nie integriert. Somit habt Ihr vielleicht eher ein Führungsproblem als ein technisches Problem.
:
Bearbeitet durch User
Unabhängig von der bisherigen Diskussion hat mich diese Form der Organisation des Repositories beeindruckt. Leider konnte ich damit in der Praxis noch keine Erfahrung sammeln: http://nvie.com/posts/a-successful-git-branching-model/ Aber vll. gibt der Link ja ein paar Anregungen.
Mark B. schrieb: > Wenn es keinen SW-Projektleiter gibt, der Termine vorgibt wann was > fertig zu sein hat (fertig = getestet und im Release integriert), dann > hat man ein Problem. Es gibt genug Gegenbeispiele zu dieser These, viele kleine und mittlere OpenSource SW Projekte brauchen gar keinen "Projektleiter", in agilen - also selbstorganisierten- Teams wird der Aufwand vom Team geschaetzt, wann was fertig ist ist eine Frage der Prioritaeten, diese werden vom Kunden (bzw. dessen Stellvertreter im Team) gesetzt. Mark B. schrieb: > In einer vernünftig geführten Abteilung kann es nicht passieren, dass > jemand jahrelang vor sich hinfrickelt und seinen Code in der ganzen Zeit > nie integriert. Somit habt Ihr vielleicht eher ein Führungsproblem als > ein technisches Problem. Das sehe ich aehnlich, wenn es keine richtige Fuehrung gibt die es schafft Teams zu formen, Leute zu motivieren und dazu bringt selbst Verantwortung zu uebernehmen, liegt es nicht an den Werkzeugen oder deren Bedienung. Erwin M. schrieb: > Ich suche Best Practice Richtlinien für Versionsverwaltung, denn in der > Firma gibt es Kollegen, insbesondere einige die nicht programmieren > können, die meinen da gehören nur freigegebene Versionen hin - Wuerde mir die Diskussion mit denen die nicht programmieren koennen ueber solche Prozesse sparen (ausser du machst das um zu informieren), denn die sollten das nicht entscheiden, falls, doch, kann/sollte man einen Arbeitgeberwechsel in Betracht ziehen.
Mladen G. schrieb: > Mark B. schrieb: >> Wenn es keinen SW-Projektleiter gibt, der Termine vorgibt wann was >> fertig zu sein hat (fertig = getestet und im Release integriert), dann >> hat man ein Problem. > > Es gibt genug Gegenbeispiele zu dieser These, viele kleine und mittlere > OpenSource SW Projekte brauchen gar keinen "Projektleiter" Die haben aber auch keine festen, dem Kunden per Vertrag zugesagten Termine einzuhalten. Ob die neue Version des Linux-Kernels nun am 17.3. oder am 18.4. kommt ist egal, da steht keine Vertragsstrafe dahinter wenn man den Termin nicht hält. > in agilen - also selbstorganisierten- Teams wird der Aufwand vom Team > geschaetzt, wann was fertig ist ist eine Frage der Prioritaeten, diese > werden vom Kunden (bzw. dessen Stellvertreter im Team) gesetzt. In manchen Firmen ist man sehr, sehr weit weg vom Kunden. Gerade in großen Konzernen besteht praktisch überhaupt kein Kontakt zwischen dem Kunden und dem Entwickler. Von daher ist dieser Weg leider nicht immer gangbar.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.