Ist es ungewöhnlich, dass ein kleines Unternehmen (15 Entwickler) keine verwaltete Quell- / Versionskontrolle einsetzt? [geschlossen]

Es handelt sich nicht wirklich um eine technische Frage, aber es gibt noch einige andere Fragen zur Quellcodeverwaltung und zu bewährten Methoden.

Das Unternehmen, für das ich arbeite (das anonym bleibt), verwendet eine Netzwerkfreigabe, um den Quellcode und den veröffentlichten Code zu hosten. Es liegt in der Verantwortung des Entwicklers oder Managers, den Quellcode manuell in den richtigen Ordner zu verschieben, je nachdem, ob er veröffentlicht wurde, welche Version er hat und welche Inhalte er enthält. Wir haben verschiedene Tabellenkalkulationen, in denen wir Dateinamen und -versionen sowie die Änderungen aufzeichnen. Einige Teams setzen außerdem Details zu verschiedenen Versionen am Anfang jeder Datei. Jedes Team (2-3 Teams) scheint dies innerhalb des Unternehmens anders zu machen. Wie Sie sich vorstellen können, ist es ein organisiertes Durcheinander - organisiert, weil die "richtigen Leute" wissen, wo sich ihre Sachen befinden, aber ein Durcheinander, weil alles anders ist und die Leute sich immer daran erinnern, was sie zu einem bestimmten Zeitpunkt tun sollen.

Ich habe seit einiger Zeit versucht, eine Art verwaltete Quellcodeverwaltung durchzusetzen, aber es scheint, als ob ich im Unternehmen nicht genug Unterstützung dafür bekommen kann. Meine Hauptargumente sind:

• Wir sind momentan verwundbar. Irgendwann könnte jemand vergessen, eine der vielen Release-Aktionen auszuführen, die wir durchführen müssen, was bedeuten könnte, dass ganze Versionen nicht korrekt gespeichert sind. Es kann Stunden oder sogar Tage dauern, bis eine Version wieder zusammengesetzt ist
• Wir entwickeln neue Funktionen zusammen mit Fehlerkorrekturen und müssen häufig die Veröffentlichung des einen oder anderen verzögern, da einige Arbeiten noch nicht abgeschlossen sind. Wir müssen Kunden auch dazu zwingen, Versionen mit neuen Funktionen zu verwenden, auch wenn sie nur eine Fehlerbehebung wünschen, da wir nur an einer Version arbeiten
• Es treten Probleme mit Visual Studio auf, da mehrere Entwickler gleichzeitig dieselben Projekte verwenden (nicht dieselben Dateien, aber es treten weiterhin Probleme auf).
• Es gibt nur 15 Entwickler, aber wir machen alle Sachen anders; Wäre es nicht besser, einen unternehmensweiten Standardansatz zu haben, dem wir alle folgen müssen?

Meine Fragen sind:

1. Ist es normal, dass eine Gruppe dieser Größe keine Quellcodeverwaltung hat?
2. Ich habe bisher für nicht mit Quellensteuerung nur vage Gründe gegeben - aus welchen Gründen würden Sie vorschlagen könnte gültig sein für nicht Quellcodeverwaltung Implementierung der obigen Informationen?
3. Gibt es weitere Gründe für die Quellcodeverwaltung, die ich meinem Arsenal hinzufügen könnte?

Ich bitte Sie vor allem, ein Gefühl dafür zu bekommen, warum ich so viel Widerstand geleistet habe. Bitte antworten Sie ehrlich.

Ich werde die Antwort der Person geben, von der ich glaube, dass sie den ausgewogensten Ansatz gewählt und alle drei Fragen beantwortet hat.

Danke im Voraus

1. Es mag nicht normal sein , aber wie Treb sagt , ist es wahrscheinlich nicht so ungewöhnlich

2. Wie bereits erwähnt, gibt es keine stichhaltigen Gründe dafür, in einem Unternehmen Ihrer Größe keine Versionskontrolle zu haben. Sie müssen also die ungültigen Gründe identifizieren und angreifen :

   a) Der wichtigste ist der Status Quo : "Wenn es nicht kaputt ist, repariere es nicht". Das ist schwierig: Sie könnten anfangen, auf all die Dinge hinzuweisen, die nicht so gut funktionieren wie sie sollten (was Sie schnell als "negative Person" auszeichnen kann), oder Sie warten einfach darauf, dass etwas in die Luft sprengt (was vielleicht niemals funktioniert) passieren), oder Sie könnten alle Dinge betonen, die schief gehen könnten . Leider sind die Menschen verantwortlich für kleine Unternehmen relativ undurchlässig für ‚Dinge , die schief gehen könnte‘ , bis sie tatsächlich tun schief gehen ...

   b) Unwissenheit / Angst / Unsicherheit : „wir nicht wirklich verstehen , was die Quellcodeverwaltung ist, wir wissen nicht, wie es zu benutzen, wissen wir nicht , welches Werkzeug zu wählen; es geht um unseren Stil Krampf“ . Dies ist ein Grund, warum ich sie definitiv nicht hierher schicken würde! Es mag für Sie selbst eine ziemlich große Herausforderung sein, aber ich denke, um Ihre Chancen zu maximieren, müssen Sie eine "schlüsselfertige" Lösung und nicht zu viele Varianten oder Alternativen präsentieren. Sie benötigen eine klare Vorstellung davon, wie Sie Ihren Arbeitsprozess anpassen / umwandeln möchten, um mit dem gegebenen Werkzeug zu arbeiten; Wie / ob Sie planen, vorhandenen Code zurückzuspielen? Wie schnell können Sie Benutzer "schulen" und zum Laufen bringen? Wie können Sie die Übergangszeit verwalten (falls es eine gibt)? wie viel es wahrscheinlich kostet (in Stunden, wenn nicht in Dollar).

   c) Es kann andere Gründe geben (z. B. schlechte Erfahrungen mit VSS in der Vergangenheit oder Horrorgeschichten über vermeintlich überkomplizierte Tools), aber Sie müssen diese einzeln abwehren, wenn Sie sie entdecken.

3. Es gibt zahlreiche Gründe für die Quellcodeverwaltung, die in den anderen Antworten aufgeführt sind. Mein Rat wäre, die wichtigsten 2 oder 3 herauszusuchen, die wirklich einen Unterschied für Ihr Unternehmen ausmachen könnten , und sie aufzufrischen und sie in einer Besprechung so vielen Ihrer Kollegen wie möglich vorzustellen. Versuchen Sie, die Diskussion zu provozieren: Auch wenn Sie sie nicht sofort überzeugen, erhalten Sie einen Einblick in die möglichen Knackpunkte.

(Haben Sie The Change Function gelesen / gehört ?)

Es ist absolut nicht normal, dass eine Gruppe dieser Größe ohne Quellcodeverwaltung arbeitet - die Größe der größten Gruppe von Programmierern, die ohne Quellcodeverwaltung effektiv arbeiten können, ist kleiner oder gleich eins. Es ist absolut unentschuldbar , ohne Versionskontrolle für ein professionelles Team jeder Größe zu arbeiten, und vielleicht fühle ich mich nicht kreativ, aber ich kann keinen Grund nennen, warum Sie darauf verzichten möchten.

Die Versionskontrolle ist nur ein weiteres Tool - ein besonders leistungsstarkes, das im Vergleich zu den minimalen Kosten enorme Vorteile bietet . Es gibt Ihnen die Möglichkeit, all Ihre Änderungen auf eine organisierte Art und Weise zu verwalten, mit allen anderen nützlichen Dingen wie Verzweigen, automatisiertes Zusammenführen, Markieren und so weiter. Wenn Sie eine Version erstellen müssen, die aus einer Vielzahl von Versionen besteht, können Sie den Code ab diesem Zeitpunkt auschecken und einfach erstellen, ohne durch andere Rahmen springen zu müssen.

Noch wichtiger ist, wenn Sie einen Bugfix schreiben müssen, können Sie ihn in ein Update einbinden, ohne die neuen Funktionen bereitstellen zu müssen, an denen Sie arbeiten seien Sie besorgt, sie existieren noch nicht.

Sie erleben Widerstand, weil Sie die Unternehmenskultur in Frage stellen. Es wird einige Zeit dauern, bis sie sich angepasst haben, egal was Sie sagen. Das Beste, was Sie tun können, ist, weiter darauf zu drängen, und wenn sich das Unternehmen wirklich nicht rührt, finden Sie einen anderen Job, der besser zu Ihrem Niveau als Entwickler passt.

Ist es normal, dass eine Gruppe dieser Größe keine Quellcodeverwaltung hat?

Nach meiner Erfahrung ist dies nicht die Norm, aber nicht so ungewöhnlich, wie andere Antworten hier vermuten lassen. Die Mehrheit der kleinen Unternehmen verwendet die Quellcodeverwaltung, eine bedeutende Zahl jedoch leider nicht.

Bisher wurden mir nur vage Gründe für die Nichteinhaltung der Quellcodeverwaltung genannt. Welche Gründe könnten angesichts der obigen Informationen für die Nichteinführung der Quellcodeverwaltung gelten?

Siehe diese Frage auf SO für eine gute Diskussion. Die akzeptierte Antwort lautet:
"Es gibt keine guten Gründe, die Versionskontrolle nicht zu verwenden. Keine."

Gibt es weitere Gründe für die Quellcodeverwaltung, die ich meinem Arsenal hinzufügen könnte?

Der Konsens unter allen Entwicklern und Projektmanagern, die ich getroffen habe, und natürlich hier bei Programmierern und SO ist, dass die Quellcodeverwaltung ein Muss ist. Es ist eine akzeptierte Best Practice . Wenn sich jemand entscheidet, es zu ignorieren, muss er einige sehr starke und überzeugende Argumente haben, warum dies die richtige Entscheidung für ihn ist (dh ein bisschen mehr als "wir haben es nie gebraucht, also warum sollten wir es in Zukunft brauchen"). Die Argumente, die Sie bisher vorgebracht haben, konzentrieren sich auf bestimmte Themen. Vielleicht sollten Sie einen umfassenderen Ansatz nach dem Motto "Jeder tut das, warum tun wir das nicht auch?" Ausprobieren.

Die Quellcodeverwaltung eignet sich auch für ein einzelnes Entwicklerteam. Jedes Quellcodeverwaltungssystem ist im Grunde ein Versionsverwaltungssystem, das den Überblick über Änderungen behält. Stellen Sie sich einen einzelnen Entwickler vor, der möglicherweise Code entfernt hat und der der Ansicht ist, dass der Code jetzt erforderlich ist. Kann er den alten Code zurückbekommen?

Suchen Sie sich einfach ein Werkzeug aus, das Ihnen hilft. Die Größe spielt nicht überall eine Rolle. Die Qualität spielt überall eine Rolle.

Es hört sich so an, als ob Sie bereits ein Versionskontrollsystem verwenden, aber kein sehr gutes. Die Leute scheinen die Notwendigkeit der Versionskontrolle bereits zu erkennen. Sie müssen sie nur in die nächste Stufe einführen - die Software-Versionskontrolle.

Wenn ich es wäre, würde ich SCM als eine verbesserte Version dessen vorstellen, was sie bereits tun. Ich möchte betonen, wie die Verwendung eines guten Werkzeugs einen Großteil der bereits laufenden Arbeit automatisiert.

• Anstatt Änderungen in einer Tabelle aufzuzeichnen, verfolgt das SCM-System nicht nur, was geändert wurde, sondern auch, wer es geändert hat und warum.

• Als Bonus können Sie zu jedem Punkt im Leben des Codes zurückkehren und sehen, was tatsächlich da war.

• Anstatt verschiedene Codeversionen in verschiedenen Ordnern zu haben und Dinge zwischen Ordnern verschieben / zusammenführen zu müssen, um eine Änderung zu portieren, können Sie alles am selben Ort aufbewahren und (was noch wichtiger ist) das Tool das Zusammenführen überlassen.

Wie andere bereits gesagt haben, würde ich einen gewissen Widerstand erwarten, also würde ich das System als Prototyp verwenden, indem ich es für die Dinge verwende, die ich tue.

(Übrigens habe ich meinen Lebenslauf und andere Dokumente tatsächlich unter SVN abgelegt. Andererseits wurden mir mehrere Male die Rollen des Konfigurations- und Integrationsmanagers übertragen.)

Ich habe bisher für nicht mit Quellensteuerung nur vage Gründe gegeben - aus welchen Gründen würden Sie vorschlagen könnte gültig sein für nicht Quellcodeverwaltung Implementierung der obigen Informationen?

• Das Produkt, das Sie entwickeln, ist ein Versionskontrollsystem. Manager sind besorgt, bestehende Produkte daran zu hindern, das Design und die Implementierung des neuen Produkts zu beeinflussen.

• Zwischen den Wochenenden, an denen BASE mit Bullen springt und läuft, fahren Manager, die Nervenkitzel suchen, gerne zur Arbeit und fragen sich, ob noch alles in die Hölle gegangen ist.

• Vermeidet feindliche Übernahmen. Wer möchte ein Softwareentwicklungs-Outfit erwerben, das auf diese Weise verwaltet wird?

Gibt es weitere Gründe für die Quellcodeverwaltung, die ich meinem Arsenal hinzufügen könnte?

• Sie führen bereits die Versionskontrolle durch, tun dies jedoch derzeit auf die am wenigsten effiziente, arbeitsintensive und fehleranfällige Weise. Die Verwendung eines VCS spart Geld, Zeit und verbessert die Qualität.

• Spart Speicherplatz. Die meisten Versionskontrollsysteme speichern nur die Deltas zwischen Dateien. Derzeit speichern Sie eine vollständige Kopie jeder Version jeder Datei. (Das Sichern all dieser Kopien muss viel Zeit und Platz in Anspruch nehmen!)

• Mehrere Entwickler können gleichzeitig an derselben Datei arbeiten und die Unterschiede ohne großen Aufwand abgleichen. Das Zusammenführen von Änderungen ist natürlich ohne ein VCS möglich, aber es ist fast unmöglich zu verfolgen, wer in diesem Fall was, wann und warum geändert hat.

• Bietet Entwicklern die Freiheit, neue Ideen auszuprobieren und zu wissen, dass sie jederzeit jede Version wiederherstellen können.

• Ein besserer Prozess erleichtert die Einstellung und Bindung talentierter Entwickler.

Ist es normal, dass eine Gruppe dieser Größe keine Quellcodeverwaltung hat?

Nein, definitiv nicht. Als ich in meiner jetzigen Firma anfing, gab es eine Person, an die Sie Ihren geänderten Code senden sollten, und er würde ihn zusammenführen. Ich konnte jeden innerhalb weniger Tage davon überzeugen , SVN zu nutzen.

Bisher wurden mir nur vage Gründe für die Nichteinhaltung der Quellcodeverwaltung genannt. Welche Gründe könnten angesichts der obigen Informationen für die Nichteinführung der Quellcodeverwaltung gelten?

Ich denke, der Grund, warum Sie nur vage Gründe gehört haben, ist, dass es keine gültigen Gründe dafür gibt, die Versionskontrolle nicht zu verwenden.

Gibt es weitere Gründe für die Quellcodeverwaltung, die ich meinem Arsenal hinzufügen könnte?

Ja, es gibt viele Gründe.

1. Durch das Verzweigen haben Sie die Möglichkeit, neue Funktionen zu entwickeln, ohne andere Entwicklungen zu beeinträchtigen.
2. Mit jedem Commit erhalten Sie Informationen darüber, was genau geändert wurde, wer diese Änderung vorgenommen hat und wann diese Änderung vorgenommen wurde.
3. Sie können problemlos Bugfixes vornehmen und diese für die Kunden bereitstellen und die unvollendete neue Funktionalität auslassen.
4. Sie können verschiedene Versionen pflegen, wenn Kunden Angst haben, zu einer neueren Version zu wechseln.
5. Sie können problemlos an demselben Projekt (auch an denselben Quelldateien!) Arbeiten.
6. Sie können einen Fehler leicht rückgängig machen, indem Sie die Änderungen nach diesem begangenen Fehler beibehalten.

Manche Menschen haben Schwierigkeiten zu erkennen, wie schlecht der Status Quo ist, bis sie etwas Besseres für sich selbst sehen. Was Sie brauchen, ist eine gute Demo . Zeigen Sie einige Beispiele für Aufgaben, die verbessert werden könnten. "Ich habe 4 Stunden gebraucht, um unser aktuelles System ausfindig zu machen, aber dieser eine Versionskontrollbefehl hat es mir sofort mitgeteilt."

Wenn Sie die Quellcodeverwaltung nicht verwenden, treten Probleme auf, selbst für einen Einzelentwickler. Die einfache Tatsache, dass Sie rücksichtslos bearbeiten können, ohne das Risiko einzugehen, etwas zu verlieren, macht den Lernaufwand innerhalb von Wochen oder Tagen wett.

Das heißt, wenn Sie Ihre Manager nicht von der Einführung der Quellcodeverwaltung überzeugen können, tun Sie sich selbst einen Gefallen und verwenden Sie zumindest etwas wie Git oder Quecksilber vor Ort einer, der es getan hat.

Mein Unternehmen verwendet GIT für die Versionskontrolle. Das Unternehmen besteht aus einem Entwickler, einem CEO, einem Sicherheitsbeamten, einer Putzfrau und einem Empfangsmitarbeiter. Sie alle sind ich. Versionskontrolle ist immer ein MUSS.

Ich arbeite selbst an vielen Projekten und benutze immer noch die Versionskontrolle. Die Größe spielt keine Rolle. Es ist immer hilfreich, eine Versionskontrolle zu haben.

Es gibt einen Grund, warum es beim Joel-Test die Nummer 1 ist: http://www.joelonsoftware.com/articles/fog0000000043.html

Es macht auch # 2 und # 3 auf der Liste möglich.

Wir waren vor ein paar Jahren in einer ähnlichen Position mit einem 6-köpfigen Team. Einer der Entwickler hat SVN auf einem Entwicklungsserver installiert, auf dem sich der freigegebene Ordner befand, und gerade damit begonnen.

Alle folgten diesem Beispiel und es dauerte nicht lange, bis wir CI ( CruiseControl ) einführten und unseren Build- und Release-Prozess um Automatisierungs- und Qualitätsprüfungen bauten.

WTF ?! Dies ist vielleicht die lächerlichste Frage, die ich je gesehen habe. Sie müssen einen neuen Job finden. 15 Entwickler ?! Sie denken, das ist ein kleines Team? Das ist verrückt. Manager sollte sofort beendet werden. Ehrlich gesagt, ich werde Albträume haben, nachdem ich diese Frage gelesen habe. Bitte teilen Sie uns das Produkt mit, das Sie verkaufen, damit wir alle wissen, dass wir es nicht kaufen sollen! Ich weiß nicht, was beängstigender ist, diese Frage oder die Antwort, dass dies nicht ungewöhnlich ist!

Ich kann mir nicht vorstellen, wie 15 Entwickler ohne Quellcodeverwaltung arbeiten können. Jedoch ab:

(...) verwendet eine Netzwerkfreigabe zum Hosten des Quellcodes (...)

Ich gehe davon aus, dass Sie eine eigene Versionskontrolle für Arme wie VSS erstellt haben (ebenfalls basierend auf einem freigegebenen Ordner). Es ist riskant und nicht effizient.

Erklären Sie Ihrem Chef, wie schlimm es ist, investieren Sie in ein zweitägiges SVN- oder GIT-Training und beginnen Sie, ein echtes Versionskontrollsystem zu verwenden, während Sie Ihren Code noch in angemessener Form haben.

Wenn ich nicht mehrmals am Tag oder zumindest bevor ich nach Hause gehe, fühle ich mich wie ... etwas fehlt, etwas falsch.

Ich habe einmal in einer Firma mit nur 2 Entwicklern gearbeitet (ich + langhaariger Administrator), damals noch 1998. Selbst dann haben wir svn benutzt. Es ist einfach so bequem.

Einige Male in meiner Karriere habe ich einen Arbeitstag verloren, weil ich etwas wie mv anstelle von cp und dann rm -rf gemacht habe. Ich musste weinen und verzweifelt in den Straßen der Stadt umherwandern.

Ich habe in den letzten 13 Jahren in 5 Unternehmen in der SE gearbeitet, an einigen Konferenzen teilgenommen und bin nie auf ein Unternehmen gestoßen, das keine Versionskontrolle verwendet.

Mein Lieblingsunternehmen für Innenarchitektur, 20 Mitarbeiter, verwendet jedoch eine weiße Tafel für Projektmanagement und Zusammenarbeit. Sie wissen, dass es einfach falsch ist, aber sie scheinen keine Zeit für ein Upgrade zu finden. Irgendwie funktioniert es aber. Frag mich nicht wie.

Sei ein Anführer. Führer zu sein bedeutet, das zu tun, was richtig ist. Probleme proaktiv lösen. Führung tut nichts, weil es nicht genug Konsens gibt. Und ein guter Leiter lernt, Situationen zu erkennen, in denen ein Konsens hergestellt werden sollte und wann dies zu tun ist. Dies ist eindeutig eine tuende Situation. Der Mangel an Code-Kontrolle wird früher oder später in Ihren Gesichtern explodieren.

Führungskräfte sind oft nicht in offiziellen Führungspositionen. Die Leute werden guten, entscheidenden Führern folgen, unabhängig vom Titel.

Wenn Ihre entschlossenen Bemühungen zunichte gemacht werden, insbesondere wenn sie vom Management stammen, ist dies ein klares Zeichen für Sie, um die Hölle loszuwerden. Es ist eine Belastung für Ihre berufliche Entwicklung; und Kompetente Entwickler und inkompetentes Management passen nicht zusammen, und eine Inkompetenz mit Leistung wird Sie fertig machen.

OK, die Rückblenden kommen auf mich zu. Abmeldung. Viel Glück.

1. Holen Sie sich eine Stoppuhr,
   • Zählen Sie die Zeit, die Sie im Arbeitsblatt nur für das Synchronisieren von Versionen verbringen
   • Zählen Sie die Zeit, die Sie mit der Reparatur defekter Versionen verbringen
   • Zählen Sie, wie oft die Leute im Flur schreien: " Ich bearbeite main.c !, nur um sicherzugehen, dass niemand anderes im Moment ist!" .
   • Zählen Sie die Anzahl der Beschwerden, die Sie von Kunden erhalten, da deren Bugfix andere Änderungen enthielt
   • Zählen Sie die Verspätung der Veröffentlichung, nur weil Sie die Versionen nicht synchronisieren konnten
2. Machen Sie aus diesen Daten einen Powerpoint und vergleichen Sie ihn mit der Funktionsweise von vcs.
3. Show-Management

Dies ist nur ein Unfall, der darauf wartet, passiert zu werden. Sie haben keine Code-Historie und auf einen Schlag könnte einer Ihrer Entwickler monatelange Arbeit zunichte machen. Als kleines Unternehmen kann man sich einen solchen Rückschlag nicht leisten.

Sie sind auch auf diesem Share-Laufwerk sehr exponiert. Wie lange können Sie es sich leisten, auch mit einem guten Backup nicht zu arbeiten? 1 Stunde, 1 Tag, 1 Woche. Wie lange würde es dauern, einen neuen Server einzurichten, von einem Backup wiederherzustellen usw. Als kleines Unternehmen haben Sie wahrscheinlich keine zusätzliche Hardware im Standby-Modus und sind möglicherweise nicht in der Lage, das Geld für einen beschleunigten Versand usw. einfach fallen zu lassen.

Denken Sie auch an externe Speicher. Eine Flut oder ein Feuer ist nicht wirklich so ungewöhnlich. Was würde passieren, wenn das Gebäude nach Stunden brennen würde? Wie viele Monate Arbeit würden verloren gehen. Ein verwaltetes Code-Repository wie Github wäre dafür wertvoll. Selbst die Verwendung eines einfachen SVN-Servers für einen gehosteten Dienst wäre in diesem Bereich ein Fortschritt.

LordScree, ich bin in einer fast identischen Situation wie Sie, mein direktes Team besteht aus ungefähr 15 Entwicklern. Ich bin im Unglauben (fast Entsetzen), dass die Quellcodeverwaltung nicht verwendet wird. Meine erste Antwort auf "Wir sollten die Quellcodeverwaltung verwenden" lautete "Wir haben keine Zeit für die Implementierung". Wie beim Tragen von Unterwäsche ist die Quellcodeverwaltung für mich nicht optional. Nach ein paar Monaten habe auch ich die Genehmigung zur Implementierung von TFS, die von der Organisation ausgewählt wurde, da es sich um MS handelt und eine 90-Tage-Testversion enthält. Unterm Strich ist es sehr schwierig, eine Organisation von der Notwendigkeit der Quellcodeverwaltung zu überzeugen, wenn sie ohne sie mitgearbeitet hat. Ich sage den Entwicklern, dass Sie immer dann, wenn Sie Dateien sichern, insbesondere mit einem Datum im gesicherten Dateinamen oder Verzeichnis, ein Beispiel dafür sind, wenn Sie etwas in die Quellcodeverwaltung aufnehmen würden. Ich ziehe an Ich habe keine brillanten Antworten für Sie, aber ich glaube, das ist ungewöhnlich. Ich kämpfe den gleichen Kampf und werde Sie über den Fortschritt auf dem Laufenden halten. Und hoffentlich wird es Fortschritte geben, wenn ich anderswo hinschaue, weil ich nicht im Chaos arbeiten kann!

Wir haben 3 Mitarbeiter in der Entwicklung und verwenden die Quellcodeverwaltung. Bei meinen persönlichen Projekten habe ich einen Entwickler und verwende die Quellcodeverwaltung. Dies ist nicht nur für das Teammanagement nützlich, sondern auch, um experimentelle Arbeiten ausführen zu können, ohne befürchten zu müssen, dass Sie etwas zerstören.

Der einfachste Weg, das Management zu überzeugen? Das Risiko für das Gesamtprodukt ist geringer und die Entwicklerproduktivität wird langfristig gesteigert. Beides ist auch wahr, und beides spricht Manager an.

Es ist keineswegs ein normales Szenario und ich denke, Sie sollten hart dafür kämpfen, dieses Setup in Ihrem Unternehmen zu bekommen. Es hat weitreichende Vorteile und es hat keinen Sinn, dasselbe zu realisieren, wenn Sie sich dem Weltuntergang nähern, und es ist nicht die Situation, unter die es fällt. Wenn es nicht kaputt ist, beheben Sie es nicht

Jeder Grund, es nicht umzusetzen, könnte nur eine Entschuldigung für schlechte Arbeit oder einen Fehler sein, der darauf wartet, geschehen zu können.

Sagen Sie ihnen einfach, wie großartig es ist, herauszufinden, was die App am 1. Januar dieses Jahres war

Wie wäre es, wenn diese Funktionalität im März hinzugefügt würde? Ich denke, wir müssen diesbezüglich ein bisschen mehr tun.

Wow, dieser Fehler 154256 wurde in diesem Commit behoben.

Ich kann die App verzweigen und die Bereitstellung senden, kein Problem, Leute, die Sie weiterarbeiten können.

Dies kann weiter und weiter gehen ... (Denken Sie daran, später Kommentare zu Commits hinzuzufügen, die als weitere Frage hinzukommen würden.)

Ich verwende die Versionskontrolle für meine Ein-Mann-Projekte und meine Arbeitsprojekte, bei denen mehr als 30 bis 40 Personen gleichzeitig am selben Code arbeiten. Die Versionskontrolle hat ihre organisatorischen Vorteile, aber die Möglichkeit, Dateien zurückzusetzen und Änderungen zu speichern, kann die Verwaltung von Code erheblich entlasten. Letztendlich ist dies das beste Szenario für Programmierer, sodass sie sich nur auf das Codieren konzentrieren können.

Die Gründe für die Nichtverwendung der Versionskontrolle sind relativ begrenzt. Mir fällt nur der technische Aspekt ein.

• Die Lernkurve ist zu lang, um den Workflow Ihres gesamten Personals in ein kostengünstiges Versionssystem umzuwandeln.
• Ihr Projektmanager ist nicht der Ansicht, dass es von Vorteil ist, den Overhead in den Workflow für die Verwaltung und Pflege eines Repositorys einzubringen. (In erster Linie ein Problem mit älteren Versionierungssystemen)

Es gibt viele Gründe, ein Versionsverwaltungssystem zu verwenden. Zumindest aufhören, Dinge zu bewegen. Arbeite mit Patches. Versionierungssysteme können genau das tun, was Sie sagen.

• Sie können zur gleichen Zeit an der nächsten Version arbeiten, in der Sie Fehlerbehebungen vornehmen, und diese separat freigeben.
• Anstatt Dateien von einem Ort an einen anderen zu verschieben, um sie zu bearbeiten, können Sie eine Verzweigung erstellen und sie nach Abschluss in den Master einbinden.
• Jeder Entwickler kann über eine eigene Kopie des Quellcodes verfügen, um zu verhindern, dass Probleme mit demselben Projekt auf mehreren Computern auftreten.
• Wenn der Code schwer beschädigt wird, kann es zu Unfällen kommen, und Sie müssen nur auf die letzte funktionierende Revisionsnummer zurücksetzen.
• Die Versionskontrolle funktioniert gut zusammen mit Bug-Trackern und kontinuierlichen Integrationssystemen.

Ich persönlich benutze als Ein-Personen-Team Versionierung, Bug-Tracking, kontinuierliche Integration, Codeüberprüfung, Überprüfung der Codekonsistenz, Komponententests, Selentests, Quellcode-Analyse, und es kann noch mehr geben, die ich vergesse. Ich gebe zu, es gibt eine leichte Lernkurve. Es gibt auch einen Kompromiss zwischen zusätzlicher Verwaltungszeit, die für die zusätzlichen Schritte erforderlich ist, die Sie automatisieren. Meiner Erfahrung nach überwiegt der ersparte Aufwand den zusätzlichen Administrationsaufwand.

Bei meinem ersten ernsthaften Job im Jahr 1990 war ich der einzige Entwickler, der in meiner Abteilung arbeitete, und wusste nicht, wie man Quellcodeverwaltung einsetzt.

Ziemlich bald danach erfuhr ich, dass ich von da an noch nie ein Projekt gesehen habe, das es nicht zu einem der ersten Dinge gemacht hat, die sie ins Leben gerufen haben.

Ich habe fast meine ganze Arbeit bei diesem Job verloren, weil ich einen Ordner auf der falschen Ebene gelöscht habe. Glücklicherweise hatte ich in der Woche zuvor eine Kopie auf einer 5-Zoll-Diskette mit nach Hause genommen und konnte die Wochenarbeit in wenigen langen Tagen wiederherstellen.

Ich halte es also für akzeptabel, wenn es das erste Projekt für alle im Team wäre und niemand es besser wüsste, aber wenn auch nur eine Person die Vorteile erklären könnte und das Team immer noch nicht zuhört, würde ich mein Projekt neu kategorisieren Die Meinung der Gruppe von "naiv" bis "gefährlich inkompetent" (Der Widerstand gegen die Verwendung eines Tools mit solch weithin nachgewiesenen Vorteilen ist fast kriminell - es ist, als hätte Ihr Team "Compilern" nicht vertraut und darauf bestanden, alles in Assemblersprache zu tun ).

Ich habe dies viel erlebt ... in kleinen Maschinenbau- / Elektronikunternehmen, in denen sie viel eingebettete Software / Hardware anbieten.

An diesen Orten ist SCM nicht Teil der Kultur der Elektrotechnik. Sie haben normalerweise einen Ingenieur pro Projekt, der nur die neueste Version sichern muss.

Das Verzweigen / Zusammenführen und sogar das Teilen von Code wird als irrelevant angesehen. Auch diese Unternehmen haben wahrscheinlich ISO9000, so dass der Prozess, albiet seltsam, wahrscheinlich dokumentiert ist.

In jedem Fall habe ich / andere Entwickler gerade angefangen, SCM persönlich zu verwenden.

Wo ich arbeite, haben wir das gleiche Problem. Ich versuche derzeit, die Quellcodeverwaltung unter das Radar zu schieben, um dieselben Probleme zu umgehen, die Sie haben. Ich verwende Fossil für die Projekte, die ich persönlich entwickle.

Ich habe kürzlich einen Server im Firmen-LAN eingerichtet, der jetzt noch komfortabler ist. Ich hoffe, dass ich, wenn ich die Nützlichkeit einiger kleinerer Projekte demonstriere, den Widerstand untergrabe und uns vom Status Quo der Netzwerkordner entfernen werde.

Die wichtigsten Gründe, warum ich kein Fossil oder ein anderes VCS verwendet habe, sind:

1. Viele der "Programmierer" sind Skriptkinder und verstehen nicht, wie man es benutzt
2. Diejenigen, die lernen könnten, denken, dass es ein Ärgernis ist, es zu benutzen
3. Diese Leute sind die alte Garde, die mit den Netzwerkordnern vertraut sind, also sollte es jeder sein
4. Niemand hat Zeit, es richtig einzurichten oder zu lernen, wie man es benutzt
5. Obwohl die Funktionen großartig sein mögen, ist keine von ihnen notwendig

Wie Sie sehen, versuche ich, diese Probleme zu umgehen, indem ich demonstriere, dass sie einfach zu verwenden, bereits eingerichtet und leicht zu erlernen sind und sich die Funktionen voll und ganz lohnen.

Selbst wenn sie die Quellcodeverwaltung nicht verwenden, befindet sich alles in einem Netzwerkbaum. Fossil kann Version alles im gesamten Baum, und Sie können es bis zu laufen , wenn eine Datei Änderung auftritt oder zumindest jede Stunde. Ich habe das für einige unserer Projekte getan, die "keine Quellcodeverwaltung benötigten" und es mir schließlich ermöglichten, zu einer guten Version zurückzukehren, wenn etwas schief ging.

Mach es richtig und sie werden nicht einmal wissen, dass du es getan hast. Dann können Sie der Held sein, der den kaputten Build wiederherstellt und zeigt, wie nützlich Ihr Werkzeug ist.

Da DVCS-Tools wie Git und Mercurial jetzt verfügbar und unglaublich einfach einzurichten und zu verwenden sind, gibt es auch für ein Team von 1 (!) Keine Entschuldigung, die Quellcodeverwaltung nicht zu verwenden. Es geht nicht um die Größe des Teams, sondern darum, einen kommentierten Verlauf Ihrer Änderungen zu haben und Workflows zu unterstützen, z. B. Produktionsprobleme zu beheben, während an einer neuen Version gearbeitet wird, und den Status des Quellcodes für verschiedene Versionen zu verfolgen.

Wenn mir ein Job in einem Team angeboten würde, das so groß gewesen wäre, und keiner der Entwickler vorgeschlagen hätte, ein VCS zu verwenden, oder wenn das "Management" sie daran gehindert hätte, würde ich es pauschal ablehnen. Es ist heutzutage einfach keine akzeptable Arbeitsweise.

Sie sollten sich sofort eine GIT-Versionskontrolle verschaffen. Sie können es sogar über Google Code Project Hosting verwenden. Wenn die anderen sehen, dass Sie Änderungen mit nur einem Klick vornehmen, während sie die Dinge manuell kopieren, ändern sie möglicherweise ihre Meinung dazu.

Wow einfach wow. Obwohl ich nicht der Meinung bin, dass dies der beste Weg ist, um mit der Code-Kontrolle umzugehen, ist es nicht ganz ungewöhnlich, dass ich in einem Unternehmen mit 6 Entwicklern gearbeitet habe und keine Quellcodeverwaltung verwendet wurde Dingsbums würde alle Änderungen überwachen. Tatsächlich lautete das Mantra, dass neue Funktionen zu Projekten hinzugefügt werden konnten, solange eine Art Schalter um die Funktionen gewickelt war.

Zum Beispiel arbeiteten wir an einem erstklassigen sozialen Netzwerk, das in PHP geschrieben war, und der Kunde wollte, dass Funktionalität in der Lage ist, ein Benutzerprofil zu abonnieren. Grundsätzlich wurde die Funktionalität in eine Prüfung wie diese eingeschlossen, wenn (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {dann den Code ausführen}

An dem Ort, an dem ich auch gearbeitet habe, hat nie mehr als ein Entwickler gleichzeitig an einer bestimmten Datei gearbeitet. Meistens war alles modular aufgebaut, sodass in diesem Fall keine Quellcodeverwaltung erforderlich war. Ich glaube jedoch, dass die Vorteile der Quellcodeverwaltung die Nachteile überwiegen, wenn sie in den meisten Fällen nicht vorhanden ist.

Die Tatsache, dass Ihr Unternehmen auf Tabellenkalkulationen zurückgreift, die Dateiänderungen dokumentieren, und was geändert wurde, als etwas wie Git oder Subversion das für Sie erledigen kann, ist absolut lächerlich.

Sie scheinen davon überzeugt zu sein, aber jemand in der Organisation ermächtigt Sie nicht dazu. Wie Sie aus den anderen Kommentaren lesen können, sollten Sie es tun.

Einige Informationen finden Sie hier: http://www.internetcontact.be/scm/?page_id=358

Der wichtigste Faktor ist, dass Ihre Kunden in die letzte "instabile" Filiale gezwungen werden. Wenn Sie aufgrund Ihrer Verträge mit Ihren Kunden für die Bereitstellung instabiler Versionen verantwortlich sind, verliert Ihr Unternehmen Geld. Sie sollten sich hier wirklich auf die Release-Stabilität konzentrieren. Dies ist der Hauptgrund für die Quellcodeverwaltung, und wie es scheint, Ihr Hauptfehler. Die anderen werden durch die Verwendung der Quellcodeverwaltung nicht so stark verbessert, da Sie bereits über alternative Systeme verfügen.