nicht angemeldet
SVN ... erste Schritte bzw. Planung
Hallo Forum,
ich arbeite zwar alleine an meinen PHP-Websites und bin dabei auch relativ diszipliniert aber will zukünftig zu zweit an einem Projekt arbeiten (können). Ausserdem habe ich nun häufig genaug gelesen, dass eine Versionierung auch alleine Sinn macht.
Nun möchte ich für die Website eines Kunden, an der ich ständig arbeite eine Versionskontrolle (SVN) benutzen und vorab erstmal planen, wie man das sinnvollerweise macht und was dazu notwednig ist.
Die Site läuft auf einem UNIX-Server und es gibt neben der Live-Domain www.example.org eine Test-Domain preview.example.org. Ich arbeite mit OS X auf meiner lokalen Entwicklungsumgebung.
Also wie läuft das ab?
danke für Tipps und
beste gruesse,
heinetz
ps. Ich habe natürlich einiges über SVN gefunden, aber das geht mir erstmal zu sehr in's Detail.
-
Guten Morgen,
also prinzipiell ist es eine gute Idee, Quellcode in ein SCM einzuchecken.
[...]
Die Site läuft auf einem UNIX-Server und es gibt neben der Live-Domain www.example.org eine Test-Domain preview.example.org. Ich arbeite mit OS X auf meiner lokalen Entwicklungsumgebung.Die Laufzeitumgebung der Anwendung ist für ein SVN irrelevant. Du benötigst irgendwo einen Server, auf dem Du ein SVN installieren und ein Repository anlegen kannst. Auf dieses Repository solltest Du Dich mit einem Subversion Client verbinden können. Hierfür gibt es mehrere mögliche Protokolle (z.B. auch HTTP, das dürfte fast überall funktionieren).
Wenn das klappt, integrierst Du in Deine Entwicklungsumgebung den SVN Client (z.B. TortoiseSVN, wenn Du keine IDE verwendest, oder ein entsprechendes SVN-Plugin für eine IDE), machst einen initialen Commit Deiner Sourcen ins Repository und fertig. Ab jetzt musst Du nur noch synchronisieren, d.h. commiten, wenn Du Neues implementiert hast, oder updaten, wenn jemand anderes etwas eingecheckt hat.Um erst mal starten zu können, und sich um die Administration nicht kümmern zu müssen, ist ein Anbieter wie z.B. projectlocker.com ein guter Anfang. Du musst halt prüfen, ob Du dem die Daten Deines Kunden anvertrauen kannst und willst.
Schöne Grüße,
Peter
-
Hello,
Die Laufzeitumgebung der Anwendung ist für ein SVN irrelevant. Du benötigst irgendwo einen Server, auf dem Du ein SVN installieren und ein Repository anlegen kannst. Auf dieses Repository solltest Du Dich mit einem Subversion Client verbinden können. Hierfür gibt es mehrere mögliche Protokolle (z.B. auch HTTP, das dürfte fast überall funktionieren).
Ich würde das Repository im Idealfall auf dem Webserver meines Kunden ablegen wollen. Mit meinem Entwicklungsrechner könnte ich die Daten dort abholen (auschecken?) und dorthin ablegen (commiten?). Das ist, glaub ich kein Problem.
Wie würde denn das konkret "verzeichnismässig" aussehen. Mit SVN verbinde ich drei Verzeichnisse '/trunk', '/tags' und '/branches'. Würde dann der DocRoot der Domain 'www.example.org' das Verzeichnis '/trunk'?
Und wohin würde der DocRoot der (Sub-)Domain 'preview.example.org' hinzeigen?
Wenn das klappt, integrierst Du in Deine Entwicklungsumgebung den SVN Client (z.B. TortoiseSVN, wenn Du keine IDE verwendest, oder ein entsprechendes SVN-Plugin für eine IDE), machst einen initialen Commit Deiner Sourcen ins Repository und fertig. Ab jetzt musst Du nur noch synchronisieren, d.h. commiten, wenn Du Neues implementiert hast, oder updaten, wenn jemand anderes etwas eingecheckt hat.
Um das ganze zu üben, habe ich mir nach diesen Artikel bei SELFHTML auf meinen Entwicklungsrechener (OS X) einen SVN-Client installiert und entsprechend das SELFTHTML-Repository ausgecheckt. Das hat auch funktioniert. Nur das sich SVN eben, dadurch, dass ich nichts comiten kann, nicht von einem gewöhnlichen Download unterscheidet. Was mich hier irritiert hat ist, dass ich nicht '/trunk', '/tags' und '/branches' heruntergeladen habe. Der Zusammenhang dieser Verzeihnisstruktur scheint mir nicht ganz klar zu sein.
Um erst mal starten zu können, und sich um die Administration nicht kümmern zu müssen, ist ein Anbieter wie z.B. projectlocker.com ein guter Anfang. Du musst halt prüfen, ob Du dem die Daten Deines Kunden anvertrauen kannst und willst.
beste gruesse,
heinetz-
Servus,
[...]
Ich würde das Repository im Idealfall auf dem Webserver meines Kunden ablegen wollen. Mit meinem Entwicklungsrechner könnte ich die Daten dort abholen (auschecken?) und dorthin ablegen (commiten?). Das ist, glaub ich kein Problem.Du kannst das Repository durchaus auf den Server Deines Kunden packen, wenn er Dir die Berechtigung gibt, bzw. Dir das entsprechend installiert.
Wie würde denn das konkret "verzeichnismässig" aussehen. Mit SVN verbinde ich drei Verzeichnisse '/trunk', '/tags' und '/branches'. Würde dann der DocRoot der Domain 'www.example.org' das Verzeichnis '/trunk'?
Dein Repository sollte aber auf jeden Fall *nicht* mit dem DocRoot irgendeiner Domain übereinstimmen. Im Repository wird das Source Code Management gemacht, in der DocRoot werden Inhalte abgelegt, die vom Webserver ausgeliefert werden sollen.
Du kannst Dein SVN-Repository ansonsten überallhin legen, wo es Sinn macht. Evtl. wäre es bei einem unixoiden System sinnvoll, einem bestimmten SVN-User das Repository ins Homeverzeichnis zu legen. Das muss aber ein erfahrener Administrator noch bewerten, ich erhalte in meinen Projekten immer ein existierendes SVN Repository.Und wohin würde der DocRoot der (Sub-)Domain 'preview.example.org' hinzeigen?
Verstehe ich nicht, ist aber im Kontext SVN egal.
[...]
Was mich hier irritiert hat ist, dass ich nicht '/trunk', '/tags' und '/branches' heruntergeladen habe. Der Zusammenhang dieser Verzeihnisstruktur scheint mir nicht ganz klar zu sein.Du checkst in der Regel nicht das Verzeichnis "trunk", "tags" oder "branches" aus, sondern deren Inhalt (bei tags und branches vermutlich einen konkreten Branch oder ein konkretes Tag). Für die Bedeutung der drei Verzeichnisse verweise ich auf die SVN-Doku, das sind Grundlagen, die Du lernen musst.
Schöne Grüße,
Peter
-
Moin,
Ich würde das Repository im Idealfall auf dem Webserver meines Kunden ablegen wollen. Mit meinem Entwicklungsrechner könnte ich die Daten dort abholen (auschecken?) und dorthin ablegen (commiten?). Das ist, glaub ich kein Problem.
Du kannst das Repository durchaus auf den Server Deines Kunden packen, wenn er Dir die Berechtigung gibt, bzw. Dir das entsprechend installiert.
Klar, das ist die Voraussetzung.
Wie würde denn das konkret "verzeichnismässig" aussehen. Mit SVN verbinde ich drei Verzeichnisse '/trunk', '/tags' und '/branches'. Würde dann der DocRoot der Domain 'www.example.org' das Verzeichnis '/trunk'?
Dein Repository sollte aber auf jeden Fall *nicht* mit dem DocRoot irgendeiner Domain übereinstimmen. Im Repository wird das Source Code Management gemacht, in der DocRoot werden Inhalte abgelegt, die vom Webserver ausgeliefert werden sollen.
Du kannst Dein SVN-Repository ansonsten überallhin legen, wo es Sinn macht. Evtl. wäre es bei einem unixoiden System sinnvoll, einem bestimmten SVN-User das Repository ins Homeverzeichnis zu legen. Das muss aber ein erfahrener Administrator noch bewerten, ich erhalte in meinen Projekten immer ein existierendes SVN Repository.Ja, das war scheinbar ein Denkfehler meinerseits. Was ich für mich klären muss ist ja in erster Linie, wie ich den vorhandenen Workflow beim Einsatz von SVN ersetze.
Im Moment habe ich einen Liveserver und eine Entwicklungsumgebung mit einem lokalen Webserver. Der Inhalt des DocRoot meines lokalen Webservers entspricht dem des Liveservers. Jetzt möchte mein Kunde auf der Seite XYX den Text "Text A" gegen "Text B" ersetzt haben. Ich nehme die Änderungen an dem betroffenen lokale File vor, die ich dann mit dem lokalen Webserver überprüfe. Danach übertrage ich das lokal geänderte Files per FTP auf den Liveserver und überprüfe, ob die Änderungen dort auch sichtbar werden. Fertig.
Wie sieht dieser Ablauf aus, wenn ich SVN einsetze?
danke für Tipps und
beste gruesse,
heinetz-
Servus,
[...]
Im Moment habe ich einen Liveserver und eine Entwicklungsumgebung mit einem lokalen Webserver. Der Inhalt des DocRoot meines lokalen Webservers entspricht dem des Liveservers. Jetzt möchte mein Kunde auf der Seite XYX den Text "Text A" gegen "Text B" ersetzt haben. Ich nehme die Änderungen an dem betroffenen lokale File vor, die ich dann mit dem lokalen Webserver überprüfe. Danach übertrage ich das lokal geänderte Files per FTP auf den Liveserver und überprüfe, ob die Änderungen dort auch sichtbar werden. Fertig.Wie sieht dieser Ablauf aus, wenn ich SVN einsetze?
Prinzipiell genau so. Nur, dass Du vor der Auslieferung in den Livebetrieb noch einen commit ins SVN machst. Dann hast Du die Dokumente zentral versioniert, und kannst bei Bedarf auf diesen Stand zurückgehen. Bei einem Release mache ich zusätzlich noch einen Tag, dann kann ich einfacher zurückrollen oder branchen, als wenn ich mir eine Revision merken muss.
Schöne Grüße,
Peter
-
Moin,
Wie sieht dieser Ablauf aus, wenn ich SVN einsetze?
Prinzipiell genau so.
Also ist die Versionsverwaltung völlig losgelöst von dem Prozess zu betrachten. Das erklärt meinen Denkfehler mit dem DocRoot und warum das Repo auch wo völlig anders liegen kann, als auf der Webserver-Maschine.
Nur, dass Du vor der Auslieferung in den Livebetrieb noch einen commit ins SVN machst.
Woran ich selbst denken muss. Ich war davon ausgegangen, dass Änderungen zwangsweise durch die Versinsverwaltung gehen.
Dann hast Du die Dokumente zentral versioniert, und kannst bei Bedarf auf diesen Stand zurückgehen. Bei einem Release mache ich zusätzlich noch einen Tag, dann kann ich einfacher zurückrollen oder branchen, als wenn ich mir eine Revision merken muss.
"Bei Bedarf auf diesen Stand zurückgehen" bedeutet in dem Zusammenhang, dass ich diesen Stand auf meinem Entwicklungssytem herstellen kann, nicht auf dem Livesystem.
Ok, danke für die Klärung!
beste gruesse,
heinetz-
Servus,
[...]
Also ist die Versionsverwaltung völlig losgelöst von dem Prozess zu betrachten. Das erklärt meinen Denkfehler mit dem DocRoot und warum das Repo auch wo völlig anders liegen kann, als auf der Webserver-Maschine.Bei mir ist das so und bei meinen Kunden auch. Technisch kannst Du das schon zusammen packen. Es macht nur in meinen Augen keinen Sinn.
[...]
Woran ich selbst denken muss. Ich war davon ausgegangen, dass Änderungen zwangsweise durch die Versinsverwaltung gehen.Für mich sind SCM und Inbetriebnahme eines Release zwei unterschiedliche Dinge. Ich checke mehrmals täglich Dinge ins SVN ein, mache aber nur alle paar Wochen oder Monate mal ein Release (nightly builds oder continuous integration ausgenommen).
[...]
"Bei Bedarf auf diesen Stand zurückgehen" bedeutet in dem Zusammenhang, dass ich diesen Stand auf meinem Entwicklungssytem herstellen kann, nicht auf dem Livesystem.s.o. Ein Release auf einem Livesystem hat nichts mit einem Checkout oder evtl. Build einer Webanwendung zu tun. Das sind unterschiedliche Dinge bei mir.
Vielleicht ist mein Arbeitsumfeld aber auch ein anderes und es sollten die Leute was zu dem Thema sagen, die Anwendungen wie Du entwickeln: Apache, HTML, CSS, JS, PHP darauf und los. Ich arbeite im Bereich Java EE, und dort ist Implementierung, Build, Deploy, Release und SCM jeweils ein eigener Part der Tätigkeit.
Schöne Grüße,
Peter
-
Moin,
Vielleicht ist mein Arbeitsumfeld aber auch ein anderes und es sollten die Leute was zu dem Thema sagen, die Anwendungen wie Du entwickeln: Apache, HTML, CSS, JS, PHP darauf und los. Ich arbeite im Bereich Java EE, und dort ist Implementierung, Build, Deploy, Release und SCM jeweils ein eigener Part der Tätigkeit.
das mag sein, kann ich aber natürlich nicht beurteilen. Ich habe vor zwei Jahren mal im Team an einem Projekt mitgearbeitet, wo SVN zum Einsatz kam. Es gab in dem Projekt einen ziemlich fitten Server-Admin, der das eingerichtet und administriert hat. Ich meine mich zu erinnern, dass meine Änderungen nach dem comit sofort auf einem Staging-Server sichtbar wurden.
beste gruesse,
heinetz-
Servus,
[...]
das mag sein, kann ich aber natürlich nicht beurteilen. Ich habe vor zwei Jahren mal im Team an einem Projekt mitgearbeitet, wo SVN zum Einsatz kam. Es gab in dem Projekt einen ziemlich fitten Server-Admin, der das eingerichtet und administriert hat. Ich meine mich zu erinnern, dass meine Änderungen nach dem comit sofort auf einem Staging-Server sichtbar wurden.So ähnlich läuft das in meinen Projekten auch. Aber für den Deploy auf einem Integrationstestsystem ist nicht SVN verantwortlich, sondern mein Continuous Integration Server (in meinem Fall Hudson). Der pollt das SVN auf Änderungen und führt bei eingecheckten Änderungen einen Build und Deploy (mit Tests) durch. Die Initiative ist aber bei Hudson, nicht bei SVN.
Schöne Grüße,
Peter
-
-
-
-
Nachtrag:
Ich habe mittlerweile diesen Artikel gefunden. Der macht's, wenn ich Dich richtig verstanden habe etwas anders. Eine Änderung führt auf diese Weise zwangsläufig durch die Versionsverwaltung.
-
Servus,
[...]
Ich habe mittlerweile diesen Artikel gefunden. Der macht's, wenn ich Dich richtig verstanden habe etwas anders. Eine Änderung führt auf diese Weise zwangsläufig durch die Versionsverwaltung.Das finde ich recht gruselig, da hier zwei getrennte Dinge vermischt werden: Source Code Management und Web Server. Technisch ist das natürlich machbar, aber es macht in meinen Augen trotzdem keinen Sinn. Ob Du es so machen willst, musst Du selbst wissen. :)
Du musst halt dem Web Server immer beibringen, was er aus dem Subversion anzeigen soll, d.h. er muss immer wissen, wie die Struktur Deines Subversion Repositories ist. Ich will das jeweils getrennt haben, weil ich vielleicht in einem Jahr nicht mehr Subversion, sondern Git für SCM verwende. Dann bleibt mein Web Server unangetastet und ich tausche das SCM aus.Schöne Grüße,
Peter
-
Moin,
Das finde ich recht gruselig, da hier zwei getrennte Dinge vermischt werden: Source Code Management und Web Server.
warum? nachem wie ich Dich und wie ich den Artikel verstanden habe, unterscheiden sich die Vorgehensweisen nur in einem Punkt:
Du checkst eine Workingcopy aus dem SCM aus und nimmst an dieser Workingcopy Änderungen vor. Abschliessend spielst Du diese Änderungen aus der Worklingcopy in das Repository ein, um den Stand dort aktuell zu halten UND spielst die Änderungen aus der Workingcopy in das Produktivsystem ein.
John Bullitt checkt genauso eine Worklingcopy aus dem Repository aus, um daran seine Änderungen vorzunehmen und spielt diese Änderungen wieder in das SCM ein, spielt aber dann die Änderungen aus dem SCM in das Produktivsystem ein.
beste gruesse,
heinetz-
Servus,
[...]
warum? nachem wie ich Dich und wie ich den Artikel verstanden habe, unterscheiden sich die Vorgehensweisen nur in einem Punkt:Du checkst eine Workingcopy aus dem SCM aus und nimmst an dieser Workingcopy Änderungen vor. Abschliessend spielst Du diese Änderungen aus der Worklingcopy in das Repository ein, um den Stand dort aktuell zu halten UND spielst die Änderungen aus der Workingcopy in das Produktivsystem ein.
Nein, ich lasse meine Änderungen durch einen CI-Server (Hudson, s.o.) in ein Integrationstestsystem deployen. Das Livesystem wird nur zu festgelegten Terminen im Rahmen eines Release erneuert. Und ein Release hat gravierende Anforderungen an Tests, Regressionssicherheit, Performance, usw. Beim Entwicklercheckin in das SCM kann das alles gar nicht berücksichtigt werden.
Schöne Grüße,
Peter
-
-
-
-
-
-
-
Hi!
Was mich hier irritiert hat ist, dass ich nicht '/trunk', '/tags' und '/branches' heruntergeladen habe. Der Zusammenhang dieser Verzeihnisstruktur scheint mir nicht ganz klar zu sein.
Ich würde die Sache mit /trunk, /tags und /branches vorerst ignorieren und mich mit den technischen Grundlagen von SVN vertraut machen: Einrichten eines Repositorys, Checkout, Update, Commit, SVN-Properties etc.
Denn: /trunk, /tags und /branches sind (von technischer Seite) einfach ganz normale Verzeichnisse. Dass diese Verzeichnisse in praktisch jedem Repository vorhanden sind, liegt daran, dass diese Struktur vorteilhaft für eine oft verwendete Vorgehensweise, die in diesem kurzen (englischen) Artikel gut erklärt wird, ist.
Wenn man die technischen Grundlagen von SVN beherrscht, dann sollte der Artikel gut nachvollziehbar sein und die Vorteile einer solchen Vorgehensweise (einfaches verwalten und bearbeiten verschiedener Versionen einer Software) auf der Hand liegen. Nur eines muss man vorher vielleicht noch wissen. Wenn du ein Repository "MeinProjekt" hast, in dem diese /trunk/tags/branches liegen, dann checkst du beim ersten SVN-Checkout nicht das Wurzelverzeichnis "MeinProjekt" aus, sondern du nimmst "MeinProjekt/trunk".
So, ich hoffe, das war einigermaßen verständlich. ;-)
Grüße
Bernhard
-
-