Stimmt etwas nicht mit der Versionskontrolle?

Ich arbeite mit einem Team von Programmierern als Business Analyst. Wir haben gerade Version 2.0 unseres Produkts veröffentlicht und arbeiten an der nächsten Version, die in 3 Monaten veröffentlicht wird (es ist ein internes Softwareprodukt). Leider hat Version 2.0 einige Probleme, die behoben werden mussten, und wir werden diese Korrekturen in ein paar Wochen bereitstellen. Das Problem ist, dass wir die Änderungen, an denen noch gearbeitet wird und die erst in drei Monaten veröffentlicht werden sollen, auch nicht bereitstellen möchten.

Die Programmierer entschieden, dass dies so gehandhabt werden sollte, dass nur der Code für die Fehler eingecheckt und der Code für die neuen Verbesserungen auf den lokalen Computern des Entwicklers aufbewahrt wird, bis sie fertig sind. Ich muss lokale Builds von ihren Rechnern zum Testen bekommen, denn wenn sie den Code einchecken und wir einen weiteren Patch herausbringen müssen, um Fehler zu beheben, möchten wir diese Verbesserungen noch nicht einbeziehen. Es gibt auch das Problem, dass dieselbe Codedatei sowohl Fehlerkorrekturen als auch Verbesserungen enthält. Sie müssen daher die Codedatei lokal kopieren, dann eine Änderung vornehmen, um einen Fehler zu beheben und diesen einzuchecken. Anschließend können Sie die Arbeit an den Verbesserungen fortsetzen, indem Sie die übernehmen lokale Kopie, die sie gemacht haben.

Es scheint ziemlich verworren zu sein - gibt es eine bessere Möglichkeit, mit dieser Art von Szenario umzugehen? Wir verwenden Team Foundation Server und Visual Studio 2010.

In V2.0 sollte ein sogenannter "Steady-State-Branch" (wir haben Perforce und nicht TFS verwendet) erstellt worden sein, sobald er veröffentlicht wurde. Alle Korrekturen für v2 wurden an diesem Zweig vorgenommen und dann in den Entwicklungszweig von v3 übertragen, während auch an v3-Features gearbeitet wurde. Dh ein Fehler auf v2 würde auch auf v3 zu einem Fehler führen.

Wenn Änderungen lange Zeit auf den Computern der Entwickler gespeichert bleiben, wird dies wahrscheinlich zu einem Integrations-Albtraum führen.

Nun, es gibt mehrere Möglichkeiten , mit solchen Problemen umzugehen, die im Allgemeinen durch Verzweigungs-Tags abgedeckt werden und jeweils unterschiedliche Vor- und Nachteile haben.

Aber von Ihren Entwicklern gewählter Ansatz ... Ich zitiere ihn mündlich, um sicherzustellen, dass ich nicht falsch verstanden habe ...

code ... wird auf den lokalen Rechnern des Entwicklers gespeichert, bis sie fertig sind ...

... der Weg wie oben ist wahrscheinlich der einzige, der völlig falsch ist!

Was es für mich kriminell macht, ist, dass es für TFS eine hervorragende, leicht verständliche Microsoft Team Foundation Server - Verzweigungsanleitung gibt - ein umfangreiches und detailliertes Dokument mit Empfehlungen für Verzweigungsstrategien, das sorgfältig auf alle Arten von Projekten zugeschnitten und erklärt wurde ( HTML - Version) hier ).

1. Ihre Entwickler haben ein grundlegendes Missverständnis hinsichtlich der Verwendung der Versionskontrolle.
2. Diskutieren Sie nicht über die "richtige" Versionskontrollsoftware. Das ist nicht das Problem.
3. Jede Code-Optimierung erschwert die Behebung des Problems.
4. WENN Sie sich entscheiden, das Richtige zu tun, können Sie die Codeänderungen nicht fortsetzen, während Sie das Problem beheben. Sie MÜSSEN die gesamte Entwicklung stoppen und den Code in die Versionskontrolle übernehmen.
5. Die Entwickler müssen den Schmerz so stark spüren, dass sie sich wenigstens hinsetzen und darüber reden können.
6. Alle Versionskontrollsoftware unterstützt grundlegende Konzepte:
   • ALLER Code wird in das Versionskontroll-Repository geschrieben.
   • Alle Codedateien haben Versionsnummern. Diese Nummern werden automatisch erhöht, wenn der Code erneut eingecheckt wird.
   • Ein TAG markiert alle Codedateien einer (und einer) bestimmten Version. So können wir zum Beispiel die Softwareversion 1 mit einem TAG versehen.
   • Ein ZWEIG ist eine "Abkehr" vom Hauptstamm .
     • Alle an einem Zweig vorgenommenen Änderungen wirken sich nicht auf den Trunk aus.
     • Sie können gegebenenfalls Zweigänderungen zu einem bestimmten Zeitpunkt wieder in den Hauptstamm einbinden.
     • Auf diese Weise können wir experimentieren, ohne befürchten zu müssen, "das Gute" durcheinander zu bringen.
7. Sie müssen die Versionskontrolle "Sprung des Glaubens" bekommen, wie ich es nenne. VERTRAUEN SIE darauf, dass das Befolgen der Grundregeln alles klar macht. Unerfahrenheit lässt uns anders denken, vertraue mir.
8. Hier ist ein anständiges Tutorial. Es ist allgemein und vollständig genug, dass Sie nicht viele andere Quellen durchsuchen müssen
   • Versionskontrolle, besser erklärt

bearbeiten

• Versionskontrolle auf Ihrem Arbeitscomputer.
  • Sie können dies jetzt ohne Teamkoordination tun
  • Auch mit Team-Versionskontrolle kann ich das nur empfehlen
  • Wenn Ihr Team Git oder Mercurial verwendet, verwenden Sie ein unabhängiges lokales Repository. So funktioniert die verteilte Versionskontrolle.
  • Sie können eine andere VC-Software Ihres Teams verwenden. Unser Team verwendet Subversion, ich verwende Mercurial lokal. Die VC-Software-Metadateien (".svn", ".mg", versteckte Ordner) stehen in keinem Konflikt.

Sie fungieren nicht als De-facto-Team-Repository. Es ist für die Verwaltung Ihrer eigenen Arbeit, Refactoring-Bemühungen usw. und CYAing selbst, während das Team weiterhin die Codebasis FUBAR.

Bearbeiten beenden

Was Sie beschreiben, ist eine schreckliche Möglichkeit, die Versionskontrolle zu verwenden. Es hätte eine Verzweigung für Release 2.0 oder ein Tag oder eine Kennung geben müssen. Auf diese Weise können Änderungen an dieser Version eingedämmt und weitere Entwicklungen durchgeführt werden.

Dieser Artikel kann Ihnen einige Ideen geben. Es wurde mit dem gitGedanken geschrieben, aber es gibt keinen Grund, warum es nicht auch funktionieren könnte mercurial. Mir ist klar, dass Sie keines von beiden verwenden, aber das ist auch ein Problem, das Sie in Betracht ziehen sollten, zu beheben.

Kurzes Antwort: Entwicklungsteam sollte einen hat getrennten Produktionszweig zu entfalteten Code-Basis V2.0 getrennt von dem halten Hauptstamm.

Alle Fehlerkorrekturen müssen zuerst in diesem Zweig durchgeführt und dann getestet und in anderen Zweigen bereitgestellt werden, damit der Code synchron bleibt .

Ihr Projekt sollte auch mehrere Umgebungen for health developmentwie Prod, Staging, QA und Dev (manchmal UAT) haben. Diese Umgebungen sollten eingerichtet werden, bevor Sie mit der Produktionsfreigabe beginnen.

Alles in allem ist die Bereitschaft zu Fehlern und Änderungen die Möglichkeit, eine freigegebene Anwendung zu unterstützen.

Da TFS als Versionskontrolle erwähnt wurde, habe ich auch eine Liste von Artikeln zusammengestellt, die hilfreich sind, um die Entwicklungsumgebung (en) für den Gesundheitszustand festzulegen:

• Implementieren von Team Foundation Server mit einem kleinen Entwicklungsteam
• Willkommen auf der TFS-Integrationsplattform!
• Teamentwicklung mit TFS Guide
• Einrichten einer Entwicklungsumgebung

Nein, denn während Sie ein VCS verwenden, führen Sie keine Versionskontrolle durch.

Das zentrale Konzept für die Versionskontrolle ist die Verfolgung von Unterschieden im Zeitverlauf. Sie planen, einige Unterschiede aufzuzeichnen, aber im Moment werden die meisten Änderungen nicht aufgezeichnet.

Wie andere gesagt haben, sollten Sie Zweige verwenden. Sobald Sie dieses Setup haben, sollten Sie alle funktionalen Änderungen einchecken (dh nicht jeden Tastendruck, sondern jedes Mal, wenn Sie einen Fehler beheben, eine Funktion hinzufügen, eine Funktion löschen oder eine Änderung auf andere Weise abschließen, sodass sie weiterhin erstellt wird und funktioniert).

Ich bin ein Entwickler, und wir erhalten einen anderen Zweigcode und eine andere Datenbank für die Korrekturen der aktuellen Version sowie einen anderen für Verbesserungen und für eine spätere nachfolgende Version.

Sobald unsere Fixes fertig sind, werden sie mit der Produktion zusammengeführt und bereitgestellt. Wir erhalten einen neuen Zweig, der wieder mit den Verbesserungen arbeitet.

Außerdem folgen wir einer Übung, wie wenn ich 10 Fixes für meine aktuelle Version habe

Ich schreibe als

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

In ähnlicher Weise mache ich dies bei anderen Korrekturen nur für jede Zeile, die ich zur Korrektur ändere oder hinzufüge. Und einfach vergleichen und festschreiben. Wenn sie parallel auf demselben Zweig arbeiten, können sie dies auch tun

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+FBefehl und Typ //Start Iteration 2, Fix No-1, Branch No-"ABC" für die Suche in der gesamten Lösung helfen sehr, genaue Positionen, Dateien mit geändertem Code und frischen Code zu finden, nur dieser Teil kann zum Festschreiben verwendet werden.