Subversion / Quellcodeverwaltung nur für Seriencode?


21

Ich habe vor einem Jahr mein Informatik-Studium abgeschlossen und arbeite jetzt bei einer kleinen Webentwicklungsfirma (ich und ein anderer Entwickler, plus Manager, Kundendienst und Tester). Bis kurz vor meinem Start gab es kein Versionsverwaltungssystem. Wir beginnen jetzt langsam mit der Implementierung von SVN, aber der andere (ältere) Entwickler (im Folgenden als Joe bezeichnet) besteht darauf, dass der einzige Code, der für unser SVN-Repository festgeschrieben werden sollte, derjenige ist, der als produktionsbereit getestet und genehmigt wurde. Dies bedeutet, dass bei größeren Projekten möglicherweise wochenlang oder länger keine Commits durchgeführt werden.

Ist das eine normale Praxis? Mir scheint, wir verlieren viele Vorteile der Quellcodeverwaltung, darunter:

  • Genaue Verfolgung des Projektfortschritts
  • Verfolgung von Problemen, sobald sie auftreten und behoben sind
  • Einfaches Zurückrollen von Fehlern
  • Einfaches Sichern von Code, sodass wir nicht viel verlieren, wenn eine Workstation ausfällt
  • Es ist einfacher, genau zu identifizieren, welcher Code an welchen Produktionsstandorten ausgeführt wird, vorausgesetzt, wir stempeln Revisionen wie hier beschrieben in ausführbare Dateien
  • Einfache Zusammenarbeit (obwohl wir keine Teamarbeit machen; es sind alles Soloprojekte)
  • Etc.

EDIT: Ich sollte betonen, dass es in der Vergangenheit keine echte Teamarbeit in diesem Unternehmen gegeben hat. Nur zwei Entwickler arbeiten an separaten Projekten. Außerdem sind viele Projekte klein, sodass sie in ein paar Wochen abgeschlossen werden können. Und das Unternehmen ist seit mehr als einem Jahrzehnt im Geschäft und kommt ohne Quellcodeverwaltung zurecht. Projekte werden normalerweise innerhalb ihres geschätzten Zeitrahmens abgeschlossen.


2
Wie motiviert er diese Idee übrigens? Wenn er Ihnen keine Gründe genannt hat, haben Sie gefragt?
Anto

8
Versteht "Joe" Branching? Einige sanfte Fragen könnten interessant sein.
James

2
@Anto - Ich denke, es lässt sich am besten mit "Es ist keine Produktion und sollte nicht Teil eines Produktions-Repositorys sein" zusammenfassen.
Mr. Jefferson

1
@ James - Ich glaube nicht, dass er SVN im Allgemeinen sehr gut kennt, also nein, ich glaube nicht, dass er etwas über das Verzweigen weiß. Aber angesichts der folgenden Antworten denke ich, dass dies die Lösung ist.
Mr. Jefferson

4
Lesen Sie diese Frage und eine kleine Stimme in meinem Kopf schrie nur "NOOOOOOOOOOOOOooooooooooo".
Kevin D

Antworten:


1

Wenn Projekte innerhalb ihres geschätzten Zeitrahmens abgeschlossen werden, kann man davon ausgehen, dass die Kunden zufriedene Kunden sind? :)

Es scheint, dass das Unternehmen auch neue Arten von Projekten aufnimmt und einige wachsende oder sich verändernde Probleme hat. Es wird viel davon ausgegangen, dass hier etwas los ist ... Bitte, trage mich!

Wenn Sie sicher sind, dass die Organisation und Kontrolle des Codes Ihnen und Ihrem Team intern helfen kann, sollten Sie SVN in Betracht ziehen, IMHO. Sie erhalten Bonuspunkte, wenn diese Route tatsächlich funktioniert und das Unternehmen in der Lage ist, qualitativ hochwertigere Produkte herzustellen, wodurch die Kunden zufriedener werden!

Seien Sie vorsichtig, wenn es den Anschein hat, als würde ein Kampf mit dem Management ein angespanntes Arbeitsumfeld schaffen. Tatsache ist, dass die Eigentümer die Firma gemacht haben. Und nicht nur das, sie haben ein erfolgreiches Unternehmen gemacht. Es ist unwahrscheinlich, dass sie einen Jackpot knacken, weil sie gut spielen können.

Sei respektvoll und du wirst vielleicht gehört.

Hoffentlich wird dies zu einem effizienteren und glücklicheren Team führen. Nach meiner Erfahrung ist dies mit einem frustrierten Management nur schwer zu erreichen.


42

Joe liegt ziemlich falsch. Jetzt können Sie das Argument anführen, dass Sie einen "sauberen" Zweig haben, der den überprüften, produktionsbereiten Code darstellt. Aber die Quellcodeverwaltung erst dann einzusetzen, wenn alles fertig ist, ist offen gesagt selbstzerstörerisch. Ein bisschen wie der Versuch, einen Martini ohne Gin zuzubereiten.


6
Bitte betonen Sie das Problem der Verzweigung und Kennzeichnung. Es ist - glaube ich - das wichtige Feature, das die Leute dazu bringt, nur in SVN auf Produktion zu bestehen.
S.Lott

3
Ein ausgezeichneter Punkt, auch mit Ihrer Vorliebe für Wodka.
Covar

Ziemlich viel? Ich würde sagen , er ist völlig falsch. Keine Frage.
Steven Evers

2
@ Covar: Ich verschmutz meinen Wodka nicht mit Wermut :)
Wyatt Barnett

22

Der "Senior" ist eigentlich sehr ungelernt. Jeder Code, der kompiliert werden kann (und Tests besteht, falls vorhanden), sollte der Quellcodeverwaltung übergeben werden. Die Quellcodeverwaltung ist eine zentrale Ressource für die gemeinsame Nutzung von Code und die schrittweise Erstellung von Software.

Der gute Punkt ist die Trennung des Produktionscodes (letzte stabile Version), aber in solchen Fällen enthält das Versionsverwaltungssystem Funktionen wie Tags / Labels und Verzweigungen.

Unser Team ist sehr misstrauisch, wenn jemand innerhalb von zwei bis drei Tagen nichts festlegt. Es bedeutet, dass er einige Probleme hat und vielleicht Hilfe braucht. Ein weiterer Punkt der Quellcodeverwaltung ist, dass diese normalerweise regelmäßig gesichert wird, was bei Entwicklungsmaschinen nicht der Fall ist. Wenn Ihre Festplatte abstürzt, verlieren Sie für einige Wochen Ihre Arbeit.


12
Er ist jedoch nicht in der Lage, als Teammitglied zu arbeiten.
Ladislav Mrnka

2
@ Tom Hamming: Beim Schneiden von Code wird keine Software entwickelt. Ich bin sicher, er kann gut programmieren, aber heutzutage ist die Versionskontrolle kein "Werkzeug" mehr, als die IDE ein Werkzeug ist. Sicher, Sie können technisch darauf verzichten, aber niemand, der bei klarem Verstand ist, tut dies.
Steven Evers

2
@SnOrfus - Obwohl ich dem Nutzen von SCM bis zu einem gewissen Grad zustimme, bezwecke ich mit dieser Frage nicht, Joe und / oder seine Fähigkeiten als Entwickler zu kritisieren. Auch hier stellt sich heraus, dass er ein großartiges Produkt ist, sich auskennt und in den letzten 10 Jahren ohne SCM klar gekommen ist. Mein Ziel bei dieser Frage war es zu sehen, ob seine Perspektive eine weit verbreitete war, der ich einfach nicht begegnet war. Schließlich bin ich gerade aus der Schule und in dieser Branche noch relativ unerfahren. Auf jeden Fall glaube ich, dass er ehrlich gesagt die Qualität und Zuverlässigkeit des Arbeitsablaufs sicherstellen möchte.
Mr. Jefferson

3
@Tom: Ich kann Ihnen jetzt sagen, dass er, unabhängig davon, was Sie von der Qualität seiner Arbeit halten, kein erfahrener Entwickler ist, wenn er nicht weiß, wie man die Quellcodeverwaltung richtig einsetzt. Es gibt keine andere Möglichkeit, außer dass er vielleicht alleine in einem Keller gearbeitet hat. Selbst in meinen eigenen Projekten, in denen ich der einzige Entwickler bin, nutze ich die Quellcodeverwaltung in vollem Umfang.
Jordanien

5
@ SnOrfus: Ich kann sehr glücklich ohne eine IDE arbeiten. Ohne Versionskontrolle werde ich nicht arbeiten. Wenn das Team es nicht benutzt, führe ich es alleine aus.
Kevin Cline

12

Abgesehen von der Frage, ob Joe Recht oder Unrecht hat (er liegt übrigens falsch), scheint es mir, dass ein Kompromiss erzielt werden könnte, wenn Sie ein verteiltes Versionskontrollsystem wie Git oder Mercurial verwenden .

Auf diese Weise würden Sie und der andere Entwickler Ihr lokales Repository bearbeiten und Ihre Änderungen frühzeitig und häufig an die Quellcodeverwaltung übergeben, Ihre Änderungen jedoch erst dann in das "Produktions" -Repository übertragen, wenn sie "als produktionsbereit getestet und genehmigt" wurden. Sie hätten eine vollständige Historie von jedem, an dem Sie im Laufe der Wochen gearbeitet haben, und Joe hätte ein makelloses Repository, in dem nur die Historie der Änderungen gespeichert war, die als produktionsbereit eingestuft wurden.


1
Ich habe darüber nachgedacht und ein wenig nachgeforscht (und gute Dinge gehört), aber mein Zögern liegt in der Tatsache, dass wir VisualSVN Server bereits gekauft und installiert haben und keiner von uns irgendwelche Erfahrungen mit Git oder Mercurial hat . Es wird noch schwieriger, wenn ich versuche, alle davon zu überzeugen, dass wir mehr Software kaufen und / oder eine vorhandene Investition wegwerfen müssen. Aber guter Punkt.
Mr. Jefferson

3
@Tom: Wenn es sich im Back-End um Subversion handeln muss, können Sie die Interoperabilitätsschicht von Gits oder Mercurial für das Material verwenden, das nicht produktionsbereit ist, und die Arbeit in Subversion verschieben, wenn es fertig ist.
Ken Bloom

2
@ Tom Hamming: Ich bin vor fast einem Jahr von SVN zu GIT gewechselt. Nach anfänglichem Fluchen fing ich an, es zu lieben (obwohl es unter Cygwin nicht so gut funktioniert wie unter Linux). Ich habe nie Geld dafür ausgegeben, ich bin ziemlich zufrieden mit der Kommandozeile und den zwei mitgelieferten kostenlosen Tools. Ich arbeite nicht einmal daran, es in meine IDE (Eclipse) zu integrieren. YMMV, aber wenn ich an deiner Stelle wäre, würde ich mein privates Git-Repo und git svnfür die Interaktion verwenden. Sie müssen nichts kaufen und niemanden überzeugen. Sie müssen es nicht einmal wissen.
Maaartinus

1
@ Tom Hamming: Als einzelner Entwickler können Sie git pushIhre Änderungen regelmäßig auf einem anderen Computer vornehmen (als Backup). Es muss nicht das "Master" -Repository sein.
Greg Hewgill

1
@ Tom Hamming: Bei SVN zu bleiben, weil Sie einen SVN-Server gekauft und installiert haben, ist ein wahrer Kostenfehler. Git und Mercurial sind beide kostenlos, und die Kosten für VisualSVN wurden bereits bezahlt. Sehen Sie sich also Ihre Optionen an, da künftig für jede Version die gleichen (Null-) Ersteinrichtungskosten anfallen.
Cercerilla

7

Es macht aus den von Ihnen genannten Gründen keinen Sinn. Es ist wie bei der Verwendung der Versionskontrolle ohne die Vorteile der Versionskontrolle.


5

Ich glaube, Joe hat nicht verstanden, dass Quellcodeverwaltungssysteme keine verherrlichten Sicherungen von Quellcode-Produktionsversionen sind, sondern ein hilfreiches Werkzeug für Programmierer, indem er die kleineren Schritte des Codefortschritts und der Reifung für Ihr zukünftiges Ich und Ihre Kollegen beschreibt. Vielleicht ist Joe es nicht gewohnt, in Teams mit anderen Leuten zusammenzuarbeiten?

Schon einmal darüber nachgedacht, warum diese Codezeile hinzugefügt wurde? Suchen Sie das Commit, das es eingeführt hat, und lesen Sie den Kommentar. Wenn Sie sich nur in der Produktion engagieren, sind die Kommentare nicht spezifisch genug, um für Sie nützlich zu sein.

Ich würde auch vorschlagen, dass Sie ein leistungsfähigeres Tool als SVN verwenden. Eine gute Einführung zu den Möglichkeiten finden Sie unter http://hginit.com/ von Joel Spoelsky.

Er verwendet Quecksilber, und es gibt heutzutage mehrere Anwärter. Git gilt als sehr mächtig, und https://github.com/ hat einige sehr, sehr nützliche Tools und bietet kostenlose Starterkonten, damit Sie es wirklich ausprobieren können.


3

Joe scheint nicht über SVN Bescheid zu wissen, sondern versucht, etwas über Zweige, Tags und Trunk herauszufinden ... Tags stimmen mit den Wünschen von Joe überein. Einiges über SVN Best Practices zu lesen würde nicht schaden


2

Ich habe noch nie SVN verwendet, daher weiß ich nicht, wie das gehen soll. Wir verwenden ClearCase, und die Praxis hier besteht darin, dass jeder Entwickler seinen eigenen Entwicklungszweig hat, dann einen Integrationszweig, den wir zusammenführen, wenn wir mit dem Testen beginnen möchten, und einen oder mehrere Versionszweige für integrierten und getesteten Code .


SVN kann das auch.
Phil Lello

2

Joe ist ein Hacker, kein Entwickler. Er klingt wie ein sehr guter Hacker, ist aber falsch, wie man die Revisionskontrolle einsetzt. Was tun?

Mir scheint, Ihre Organisation hat eine Investition in SVN und es wäre eine Karrierebegrenzung für Sie, Joe herauszufordern und die Dollar-Investition in den SVN-Server ungültig zu machen. Richten Sie ein GIT-Repo ein und verwenden Sie die git svn-Schnittstelle, um so zu arbeiten, wie Sie möchten (Dies ist alles freie Software und die Einrichtung dauert eine Stunde bis einen Tag, alles auf Ihrer Workstation). Sozialisieren Sie Ihren Workflow mit Joe - er kann sein "unverschmutztes SVN-Repo" -Glaubenssystem bewahren und seine Glaubwürdigkeit gegenüber dem teuren weißen Elefanten in der Ecke (und dem Ego) bewahren.

Ich gehe davon aus, dass Joe in Kürze nachsehen wird, wie Sie arbeiten, und dasselbe tun wird. In ein oder zwei Jahren wird der SVN-Server ein Git-Repo.


Dollar-Investition in SVN-Server wäre nicht mehr als die Dollar-Investition in ein Git-Repo-Server ...
TZHX

2

Sie könnten versuchen, Joe mit den obigen Argumenten zu überzeugen. Wenn dies nicht gelingt, verwenden Sie SVN lokal für Ihre eigene Entwicklungsarbeit und hoffen, dass es irgendwann von Joe abgeholt wird. Wenn Sie sie nicht mit Argumenten überzeugen können, tun Sie das, wovon Sie überzeugt sind, und zeigen Sie, dass es funktioniert. Art des verteilten Ansatzes, aber mit den vorhandenen Werkzeugen.


2

Ich werde hier @ Carson63000 wiederholen und sagen, dass ich diese Einstellung schon einmal gesehen habe und dass sie größtenteils durch die schrecklichen Verzweigungs- / Zusammenführungsfähigkeiten des VCS verursacht wird. Ein Zweig, der mit Tags für jede Version kompiliert und Tests besteht, ist ein großartiger Ansatz, der jedoch nicht bis zu dem Punkt befolgt werden sollte, an dem kein anderer Code festgeschrieben wird. DVCS im Allgemeinen und Git im Besonderen machen das Verzweigen zu einem einfachen und allgemeinen Vorgang, und es verringert einen Großteil der Schwierigkeiten mit diesem Workflow.


1

Der Grund, warum Versionskontrollsysteme Tags unterstützen, liegt darin, dass Sie den zertifizierten Code kennzeichnen können und Ihre tägliche Arbeit dennoch ausführen können. Immer wenn Sie einen Produktionsqualitätscode haben, übergeben Sie ihm ein Etikett, und Sie sind fertig. Sie kennen den genauen Zeitpunkt, zu dem Sie zurückkehren müssen, um das zu erhalten, was der Kunde hat. Und Sie können immer verschiedene Versionen Ihres Codes überprüfen und vergleichen. Auf diese Weise können Sie beide mit Ihren Daten in der Quellcodeverwaltungsdatenbank zufrieden sein. Es funktioniert für das Unternehmen, für das ich arbeite, mit 100 Entwicklern, die alle am selben Projekt arbeiten. Es wird definitiv auch für Sie funktionieren.


0

Es ist durchaus üblich, Dinge nur in Versionskontrollsystemen zu lagern, die zur Auslieferung an die Produktion bereit sind. So wird es in der Vergangenheit seit Jahrzehnten gemacht, seitdem Festplattenspeicherung Hunderte von Dollar pro Megabyte kostete und alles zu teuer war.

Es wird nicht mehr als die beste Methode angesehen, aber ich kann verstehen, warum die Leute es immer noch tun, da es immer noch viele ältere Versionskontrollsysteme gibt, die es schwierig, wenn nicht unmöglich machen, etwas anderes zu tun, und trotzdem wissen, was Sie tun Jede Veröffentlichung ist (oder besser gesagt, es gibt keine Möglichkeit, zu wissen, was eine Veröffentlichung ist, ohne die Tags in jeder einzelnen Datei zu überprüfen, wenn Sie zurückgehen müssen. Ich habe mehr als ein Repository gesehen, in dem die einzige Möglichkeit besteht, eine alte zurückzuerhalten release sollte eine zip-Datei mit dem Quellcode und den Binärdateien für dieses Release aus dem Repository abrufen.


Interessanterweise sollten Sie beachten, dass Binärdateien enthalten waren. Wir haben eine separate Diskussion, ob die kompilierten Binärdateien in die Quellcodeverwaltung einbezogen werden sollen. Ich sage nein, weil es Platz verschwendet und bedeutet, dass Sie Ihre Kasse einfach durch Kompilieren verschmutzen können. Warum wurden kompilierte Dateien historisch aufgenommen?
Mr. Jefferson

Die Binärdateien wurden eingeschlossen, da es unmöglich war, die Quellen einer Veröffentlichung zuverlässig wiederherzustellen. Die Binärdateien wurden stattdessen gespeichert, falls sie jemals benötigt würden, um einen Server auf eine ältere Version zurückzusetzen.
Jwenting
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.