Willkommen auf dem Portal für Mediengestalter
|
|
Autor |
Nachricht |
new001
Threadersteller
Dabei seit: 16.02.2006
Ort: Sundern
Alter: 37
Geschlecht:
|
Verfasst Mo 16.07.2012 16:11
Titel Welches Versionierungssystem ist geeignet? |
|
|
Hallo Zusammen,
ich würde gerne für uns ein Versionierungssystem installieren, jedoch weiß ich nicht welches für uns am Besten geeignet ist, vlt. könnt ihr mir dabei helfen. Hier mal mein Vorhaben:
Wir haben einen Entwicklungsserver und einen Produktionsserver, beide (Linux) dezentral. Nun möchte ich vermeiden, das sich jeder XAMPP auf dem lokalen System installiert und dort entwickelt. Lieber hätte ich es so, das jeder am Entwicklungsserver arbeite, dort die Dateien gesperrt werden, die der Benutzer gerade bearbeitet. Nach erfolgreichem Schließen der Datei wird die Datei wieder frei gegeben, so das andere Entwickler daran schreiben können.
Wenn alle Entwickler ihr Werk fertig gestellt haben, möchte ich, teile der Entwicklerversion (Config Dateien mit Datenbank-Hosts etc. ausgeschlossen) auf den Produktionsserver übertragen/mergen.
Jemand nen Vorschlag?
Viele Grüße
Paul
|
|
|
|
|
bacon
Dabei seit: 24.10.2007
Ort: -
Alter: -
Geschlecht: -
|
Verfasst Mo 16.07.2012 17:24
Titel
|
|
|
So wie Du Dir das vorstellst, ist das quatsch. "Normalerweise" entwickelt tatsächlich jeder an seiner eigenen Kiste, der Quellcode steht allgemein unter Versionskontrolle durch ein beliebiges VCS (CVS, Subversion, ein wenig moderner: git sind bekannte Vertreter).
Steht der Code, der auf die Integrationsserver deployed wird, ebenfalls unter Versionskontrolle, kannst Du Änderungen an den Sourcen (neue Releases) jederzeit mit einem simplen Kommando übernehmen. Blacklists (svn ignore, gitignore) können Dir dabei helfen, nicht änderliche Dateien (Konfigurationen, Buildscripts etc.) von Änderungen per se auszuschließen. Effektiver geht das aber mit einem vernünftigen Environment-Management.
CI-Server wie der olle Jenkins bspw. können Dir die leidliche Arbeit abnehmen und den Aktualisierungsvorgang hübsch automatisieren.
P.s. wenn ihr hauptsächlich LAMP-Stacks benutzt, würde ich von Windows schnell abrücken und ebenfalls auf einer Unixoiden, der Zielplattform entsprechenden Umgebung entwickeln.
Zuletzt bearbeitet von bacon am Mo 16.07.2012 17:25, insgesamt 1-mal bearbeitet
|
|
|
|
|
Anzeige
|
|
|
new001
Threadersteller
Dabei seit: 16.02.2006
Ort: Sundern
Alter: 37
Geschlecht:
|
Verfasst Mo 16.07.2012 17:57
Titel
|
|
|
Danke für deine schnelle Antwort, aber genau das ist das was ich vermeiden will.
Ich will vermeiden, das sich jeder Developer jedes mal eine aktuelle Version ziehen muss, nur weil irgendwer irgendwelche Änderungen gemacht hat, die sich auf sein Feature auswirken.
|
|
|
|
|
bacon
Dabei seit: 24.10.2007
Ort: -
Alter: -
Geschlecht: -
|
Verfasst Mo 16.07.2012 18:09
Titel
|
|
|
Was willst Du genau vermeiden? Dass es Konflikte dabei gibt? Das vcs zeigt etwähige Konflikte an und listet sie zur Auflösung auf. Konflikte sollte es sowieso nur selten geben, wenn das häufiger unkontrolliert vorkommt, stimmt generell im Arbeitsablauf was nicht.
Zitat: | Ich will vermeiden, das sich jeder Developer jedes mal eine aktuelle Version ziehen muss, nur weil irgendwer irgendwelche Änderungen gemacht hat, die sich auf sein Feature auswirken.
|
Das ist aber täglich Brot. Du bist da aufm völlig falschen Dampfer... Lies Dir die Thematik doch mal an.
|
|
|
|
|
pantonine
Dabei seit: 03.03.2011
Ort: gehen Sie bitte weiter…
Alter: -
Geschlecht: -
|
Verfasst Mo 16.07.2012 19:34
Titel
|
|
|
Dein Ziel ist absolut illusorisch.
1. Arbeit an jedem nicht-trivialen System erfordert, dass Du im Alltag an mehr als einem Script „gleichzeitig“ (im Änderungsprozess) arbeiten wirst.
2. Jede Änderung sofort einzuchecken ist illusorisch, weil aufwendig und widerspricht dem Versionierungsgedanken. Nämlich sinnvolle funktionale Zwischenstände abzulegen.
3. Dein Verständnis von Versionierung ist falsch. Es geht eben nicht darum, Ressourcen zu sperren.
4. Und wenn, wäre das ein absolut grausames arbeiten, wenn jeder auf die Änderungen des Kollegen warten müsste.
5. Direktes Arbeiten auf dem Server verlangsamt den Dateizugriff und damit den Arbeitsprozess.
Tipps:
1. Projektarbeit wird möglichst auf verschiedene Bereiche verteilt
2. Jeder entwickelt lokal. Bei Bedarf versioniert die Entwicklungsumgebung halt mit. (oder deren Konfiguration)
3. Ich empfehle ein verteiltes Versionierungssystem wie Git oder Mercurial
4. Sinnvolle Zwischenstände werden sauber beschrieben versioniert. Konflikte werden gemeinsam ge„mergt“
5. Funktionale/Fertige Bestandteile werden in das Haupt-Repo gepusht.
Zitat: | Ich will vermeiden, das sich jeder Developer jedes mal eine aktuelle Version ziehen muss, nur weil irgendwer irgendwelche Änderungen gemacht hat, die sich auf sein Feature auswirken.
| FDas ließe sich auch mit Deiner Variante nicht vermeiden. Es reicht ja, wenn jemand einen Teil einer API geändert hat. Auch wenn Du nicht direkt an der Datei arbeitest, wirkt sich das bspw. auf aufrufende Bestandteile aus.
Zuletzt bearbeitet von pantonine am Mo 16.07.2012 19:35, insgesamt 1-mal bearbeitet
|
|
|
|
|
phihochzwei
Moderator
Dabei seit: 08.06.2006
Ort: Mülheim an der Ruhr
Alter: 46
Geschlecht:
|
Verfasst Mo 16.07.2012 20:55
Titel
|
|
|
Hinzukommt, das deine Konstellation den gesamten Arbeitsfluss extrem ausbremsen würde/könnte.
Vertrau doch einfach mal darauf, das Millionen Entwickler vor Dir nicht vollkommen synoptisch entkoppelt sind.
|
|
|
|
|
sahnemuh
Dabei seit: 19.06.2003
Ort: /dev/null
Alter: 42
Geschlecht:
|
Verfasst Mo 16.07.2012 22:57
Titel
|
|
|
Wenn du vermeiden willst, dass die workspaces jeweils auf dem rechner des entwicklers liegen, kannst du auch einen groß dimensionierten (oder mehrere kleine) server hinstellen: jeder entwickler bekommt auf dem server einen eigenen benutzer und die home directorys werden jeweils z.B. per ssh gemountet und "wie ein lokales laufwerk" genutzt.
vorteil: es gibt keine unterschiede in der konfiguration / hardware etc.
voraussetzung: schnelle internet / wan / lan anbindung bei den entwicklern und ein entsprechend dimensionierter, performanter server (vorzugsweise im selben netz).
ich habe so ein mal in einem großen projekt als externer entwickler gearbeitet und fand es zwar gewöhnungsbedürftig aber vom konzept ganz nett.
was die versionierung angeht: was die andern sagen!
dateien sperren ist unfug (habe bis vor kurzem mit einem properitäten vcs gearbeitet, in dem es so funktionierte: das war die hölle!). halt dich an z.B. git oder wenn es sein muss svn und vergiss diesen quatsch.
Zuletzt bearbeitet von sahnemuh am Mo 16.07.2012 22:58, insgesamt 1-mal bearbeitet
|
|
|
|
|
DEKONSTRUKTIV
Dabei seit: 22.06.2009
Ort: bln
Alter: -
Geschlecht: -
|
Verfasst Mo 16.07.2012 23:54
Titel
|
|
|
wozu soll denn so gammliger filer für n paar handvoll entwickler großzügig dimensioniert sein?
|
|
|
|
|
|
|
|
Ähnliche Themen |
Community CMS - Welche ist dafür geeignet
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|