Hallo, wir würden gerne bei uns in der kleinen Firma Subversion verwenden. Jetzt bestehen sorgen, dass man das nicht gescheit ans Laufen bringt und die Repositorys evtl. mal Schaden nehmen und hier nichts mehr läuft. Natürlich würden regelmäßig Backups gemacht, aber es ist und bleibt ein heißes Eisen, da leider keiner eben genau weiß wie das geht. Um nun den Qualitäts-Beauftragten und den Prozess-Auditor zufrieden zu stellen wird jetzt eine Fachfirma gesucht. Ich habe nur leider keinen Plan, auf welcher Art von Platform ich dannach suchen soll. Sowas steht ja auch nicht im Telefonbuch. Hat jemand einen Tip?!
kann auch git empfehlen. Google liefert zu 'git Schulung' reichlich Ergebnisse, kommerzielle Anbieter sowie Udemy oder sonstige YT Einstiege. Server aufsetzen ist dank fertiger Templates auch kein Hexenwerk, gitlab-CE oder jetzt gibt es auch ein schlankeres gitea.
Danke für die Antworten erstmal. An GIT haben wir natürlich auch erst gedacht. Auf den ersten Blick scheint man aber von zentral gespeicherten Repositorys besser Backups machen zu können als von dezentralen. Ich bring mal einen naiven Gedanken: Was ist, wenn jemand eine Änderung macht. Nach erledigter Arbeit wird der PC heruntergefahren. Backups werden in der Nacht gemacht, allerdings ist garkein PC eingeschaltet.
Auch bei git hat man einen (oder mehrere) Remotes wo man seine Kopie hinschiebt. Das jedes lokale Repo eine komplette Historie enthalten kann ist doch ein geniales Feature. Wichtig ist ein guter Workflow und das nicht jeder gleich in den main branch schreiben darf.
Hans K. schrieb: > Auf den ersten Blick scheint man aber von zentral gespeicherten > Repositorys besser Backups machen zu können als von dezentralen. nur weil man git "dezentral" ("distributed graph") nutzen kann, heißt das nicht, dass man es auch muss. Genauso kannst du einen zentralen Git-Server (bare repo oder mit Oberfläche gitlab/gitea/...) hinstellen, in den die Entwickler ihre Branches zu pushen haben. Wenn ein Entwickler Daten an der Versionsverwaltung und Backup vorbeischummeln will, kriegt er das in beiden Systemen hin.
Nimm wirklich lieber git. Wir haben vor ca 7 Jahren von SVN auf git umgestellt - und das fand ich schon spät. Zum Rest wurde schon alles gesagt, wenn jemand nicht „pusht“ dann ist es eben noch nicht Remote. Daher sollte man das auch regelmäßig tun. Bei SVN wäre das aber nicht anders wenn jemand nicht regelmäßig „comittet“
1. git statt svn 2. Deine Kernfrage zielt auf "keiner eben genau weiß", QM, Prozess und Audit. Du könntest dir vor Ort einen IT-Dienstleister/Web-Frickler/ähnliches suchen. Wenn die einigermaßen auf Höhe der Zeit sind, nutzen die selbst Versionsverwaltung und würden dir bestimmt auch Support gegen Münzeinwurf anbieten. Wird aber teuer und ist (meine Erfahrung) auch nicht das Gelbe vom Ei. Mein Tipp: Sprich mit deinem QM/Auditor ab, dass ihr In-House-Kompetenz für dieses Thema aufbaut, so richtig mit Verantwortlichem, Prozess- und Anwenderdokumentation, etc. Hat den Vorteil, dass es euch (a) günstiger kommt und ihr (b) dann anschließend genau wisst, was da wie läuft und das System auch euren eigenen Vorstellungen anpassen könnt. Das ganze System aufzusetzen ist auch nicht so dramatisch, lässt sich mit Büchern/Web, ggfs. vielleicht noch einer Schulung und (ganz wichtig) gesundem Menschenverstand lösen. Aus QM-Sicht ist nur wichtig, dass der Prozess definiert und dokumentiert ist und beherrscht wird, das wäre dann gegeben und ihr könnt euch den Stress mit Externen sparen.
Hans K. schrieb: > wir würden gerne bei uns in der kleinen Firma Subversion verwenden. > Jetzt bestehen sorgen, dass man das nicht gescheit ans Laufen bringt und > die Repositorys evtl. mal Schaden nehmen und hier nichts mehr läuft. > Natürlich würden regelmäßig Backups gemacht, aber es ist und bleibt ein > heißes Eisen, da leider keiner eben genau weiß wie das geht. Hast Du es schon mal mit einem Buch versucht? https://svnbook.red-bean.com/ Das ist DAS svn-Buch von den Entwicklern. Da steht alles drin, was es zu svn zu wissen gibt, inkl. Server-Konfiguration mit svnserve (einfach) und apache plus mod_svn (nicht ganz so einfach) und Backups etc. Lesen, kleines Testsystem aufbauen und sich daran einarbeiten und dann ausrollen. Das Buch gibts wahlweise auch auf Papier. fchk
Ich fürchte, dass der Wechsel zu git für Hans K. nichts nützt, denn auch Subversion funktioniert normalerweise sehr zuverlässig. Git ist etwas komplexer zu bedienen. Wenn seine Leute schon mit Subversion Bockmist bauen, dann wird das mit Git wohl erst recht passieren. Ich würde her mal nachforschen, was genau schief gelaufen ist. Da kann durchaus ein Hardwaredefekt hinter stecken. Hier ist mein Aufsatz zu Git: http://stefanfrings.de/git/index.html
Stefan F. schrieb: > . Wenn seine Leute schon mit Subversion Bockmist bauen, dann wird das > mit Git wohl erst recht passieren. > Ich würde her mal nachforschen, was genau schief gelaufen ist. Wo liest du sowas aus dem Eröffnungsbeitrag?
Hans K. schrieb: > wir würden gerne bei uns in der kleinen Firma XXXXX verwenden. Jetzt > bestehen sorgen, dass man das nicht gescheit ans Laufen bringt und > die Repositorys evtl. mal Schaden nehmen und hier nichts mehr läuft. Ja. So ist das mit jeder Software. Man muß sich darauf einlassen und ein Minimum an Eigenleistung erbringen. Sonst geht es irgendwann mal schief. Ganz egal ob das GIT oder SVN oder CVS oder sonstwas ist. Man kann (in gewissen Grenzen) Zeit gegen Geld traden, indem man konstenpflichtige 3rd-Party Services in Anspruch nimmt. Dann muß man sich z.B. nicht um Backups kümmern. Das war es dann aber. Speziell bei einen Versions-Kontrollsystem würde ich aber auch darauf achten, die Anwender auch zu schulen. Und speziell bei GIT, wo man so viel Möglichkeiten hat, den Workflow zu organisieren, würde ich es für zwingend erachten, den Workflow zu dokumentieren.
Alte weiße frau mit Pines schrieb: > git verwenden. Das würde ich zwar auch empfehlen, ändert aber an der Problematik nichts. Εrnst B. schrieb: > nur weil man git "dezentral" ("distributed graph") nutzen kann, heißt > das nicht, dass man es auch muss. Genauso kannst du einen zentralen > Git-Server (bare repo oder mit Oberfläche gitlab/gitea/...) hinstellen, > in den die Entwickler ihre Branches zu pushen haben. Ich würde sagen, dass das das übliche Nutzungsszenario ist. Der Vorteil bei git gegenüber svn ist, dass mir das Repo immer noch zur Verfügung steht, wenn ich mal keine Server-Verbindung habe. Ich kann immer noch z.B. commits machen oder gegen frühere Versionen diffen. Bei svn ist dafür eine permanente Serververbindung nötig. Wilhelm W. schrieb: > Mein Tipp: Sprich mit deinem QM/Auditor ab, dass ihr In-House-Kompetenz > für dieses Thema aufbaut, so richtig mit Verantwortlichem, Prozess- und > Anwenderdokumentation, etc. Hat den Vorteil, dass es euch (a) günstiger > kommt und ihr (b) dann anschließend genau wisst, was da wie läuft und > das System auch euren eigenen Vorstellungen anpassen könnt. Das ganze > System aufzusetzen ist auch nicht so dramatisch, lässt sich mit > Büchern/Web, ggfs. vielleicht noch einer Schulung und (ganz wichtig) > gesundem Menschenverstand lösen. Da muss man vorsichtig sein, denn in der Regel ist das nicht genug Arbeit, dass das ein Mitarbeiter dediziert machen kann. Wenn dann aber irgendeiner auserkoren wird, das "nebenher" zu machen, dann bleibt das Zeug liegen, wenn der in einem Projekt vergraben ist. Und wenn der mal im Urlaub oder krank wird und dann der Server ausfällt, wird's blöd. Klar kann man noch einen Vertreter befähigen, aber ich hab schon erlebt, wie schlecht das funktionieren kann. Es ist halt für die Entwickler ein recht essenzielles System, das stabil, sauber und sicher funktionieren muss, inklusive allem, was es da bei Servern allgemein zu beachten ist. Dann doch lieber extern die Kompetenz einkaufen. Axel S. schrieb: > Speziell bei einen Versions-Kontrollsystem würde ich aber auch darauf > achten, die Anwender auch zu schulen. Und speziell bei GIT, wo man so > viel Möglichkeiten hat, den Workflow zu organisieren, würde ich es für > zwingend erachten, den Workflow zu dokumentieren. Dann ist es aber mit git alleine nicht getan. Da braucht man dann noch einen Issue-Tracker wie Jira oder Gitlab.
Danke soweit für die konstruktiven Vorschläge.
Ich muss zugeben, dass mir nicht klar war, dass GIT auch als
Server-Lösung funktioniert. Ich habe mir das mal hier
https://git-scm.com/book/en/v2
angeschaut.
Wilhelm W. schrieb:
> Mein Tipp: Sprich mit deinem QM/Auditor ab, dass ihr In-House-Kompetenz
> für dieses Thema aufbaut, so richtig mit Verantwortlichem, Prozess- und
> Anwenderdokumentation...
Das kommt sowieso, auch soll das Know-How Intern aufgebaut werden. Der
Entwicklungsprozess ist momenentan vollständing dokumentiert und soll
dahingehend erweitert werden.
Wir haben natürlich keine Person, die sich Vollzeit um die IT kümmert,
das wird so nebenher gemacht, und wenn es eng wird kommt der
IT-Dienstleister. Leider hat er keine Ahnung von
Versionsverwaltungssystemen, muss er auch nicht.
Le X. schrieb:
> Stefan F. schrieb:
>> . Wenn seine Leute schon mit Subversion Bockmist bauen, dann wird das
>> mit Git wohl erst recht passieren.
> Wo liest du sowas aus dem Eröffnungsbeitrag?
Danke Le X. Um es nochmal klar zu stellen, bisher wurde noch nichts
installiert.
Zurück zum Thema: Ich musste feststellen, dass es für GIT definitiv mehr
Ansprechpartner gibt, als für SVN (wenn es überhaupt welche gibt). Das
ist definitiv ein Argument für GIT. Damit kann ich erstmal arbeiten.
Danke!
Hans K. schrieb: > Zurück zum Thema: Ich musste feststellen, dass es für GIT definitiv mehr > Ansprechpartner gibt, als für SVN (wenn es überhaupt welche gibt) gab SVN verwendet kein Mensch mehr der bei Verstand ist wenn er nicht unbedingt muss. Historisch wurde das durchaus genutzt und hatte eine gewisse Verbreitung, aber wenn jemand ein System einführt, dann greift eigentlich keiner mehr zu Subversion sondern heutzutage direkt zu git. Gibt natürlich immer ein paar Ewiggestrige welche darauf beharren dass git so kompliziert sei und SVN deutlich einfacher, das ist natürlich Blödsinn, wenn mehrere Entwickler an einem Projekt arbeiten ist eine Zusammenarbeit mit SVN kaum sinnvoll möglich. Die paar Grundbefehle beherrscht ein Entwickler nach 2 Minuten, wenn die Mitarbeiter nicht dazu fähig sind würde ich mir als Arbeitgeber direkt die Förderung vom Staat für die Anstellung von geistig "besonderen" holen. Du willst einen Server bei euch in der Firma mit Bitbucket/Gitlab/etc. welcher eine Weboberfläche für Pull Requests usw. bietet, alles andere ist Murks. Zudem willst du eine Lösung an die du z.B. einen Jenkins für automatische Builds anbinden kannst (lasst euch auf keinen Fall Bamboo andrehen, der totale Rotz). Als Ticketsystem ist Jira nicht schlecht.
Rudolf schrieb: > SVN verwendet kein Mensch mehr der bei Verstand ist wenn er nicht > unbedingt muss. Ziemlicher Quatsch. git ist halt flexibler und kann mehr und wird daher heute bevorzugt verwendet, aber svn ist ein solides Versionierungstool. > Historisch wurde das durchaus genutzt und hatte eine gewisse Verbreitung, Es war das bei weitem meistgenutzte Versionierungstool. > Gibt natürlich immer ein paar Ewiggestrige welche darauf beharren dass > git so kompliziert sei und SVN deutlich einfacher, das ist natürlich > Blödsinn, wenn mehrere Entwickler an einem Projekt arbeiten ist eine > Zusammenarbeit mit SVN kaum sinnvoll möglich. Steile These. Immerhin wurde über viele Jahre hinweg der weit überwiegende Teil aller OpenSource-Projekte damit sehr gut über die ganze Welt verteilt entwickelt, egal ob das jetzt z.B. Firefox, KDE oder GCC ist. Alle haben sie das verwendet, und es hat sehr gut funktioniert. > Du willst einen Server bei euch in der Firma mit Bitbucket/Gitlab/etc. > welcher eine Weboberfläche für Pull Requests usw. bietet, alles andere > ist Murks. Oben wirfst du svn vor, angeblich für Zusammenarbeit unbrauchbar zu sein. Nun, wie du hier feststellst, ist git das für sich alleine ohne diese Zusätze auch. > Zudem willst du eine Lösung an die du z.B. einen Jenkins für automatische > Builds anbinden kannst (lasst euch auf keinen Fall Bamboo andrehen, der > totale Rotz). Bamboo funktioniert bei mir recht gut, auch wenn ich mir für die automatische Übernahme der Testergebnisse aus ctest was basteln musste, weil's kein brauchbares Bamboo-Plugin dafür gab. Allerdings habe ich nicht den Vergleich zu Jenkins.
:
Bearbeitet durch User
Rolf M. schrieb: > Bamboo funktioniert bei mir recht gut, auch wenn ich mir für die > automatische Übernahme der Testergebnisse aus ctest was basteln musste, > weil's kein brauchbares Bamboo-Plugin dafür gab. Allerdings habe ich > nicht den Vergleich zu Jenkins. Jenkins kann auch nicht zaubern. Je nachdem was du Automatisieren möchtest und ob du noch Testergebnisse auswertest usw. brauchst du auch jede Menge gluecode. D.h. bei komplexeren Builds häkelst du dir auch ein Sammelsurium an Skripten um deine Jobs zu wrappen. Von dem her haben beide Systeme ihre Darseinsberechtigung, genau wie bei der Diskussion bzgl. git und svn.
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.