Forum: PC-Programmierung Versionsverwaltung für Webseite?


von Schmiedl (Gast)


Lesenswert?

Hallo,

ich bastel gerade für Verwandte eine Firmenwebseite.
Als CMS kommt Joomla zum Einsatz.

Momentan arbeite ich noch offline mit lokalem Apache, demnächst wird die 
Seite mal Live gehn und fehlender Inhalt nach und nach eingepflegt.

Ich komm eigentlich aus der Embedded Ecke und bin es gewohnt, eine 
Versionsverwaltung zu nutzen. Daheim fürs Hobby nutze ich z.B. git.

Nun stellt sich mir die Frage, ob es nützlich ist für eine 
Web"entwicklung" ebenfalls auf git zurückzugreifen. Gerade wenn man mit 
Templates, PlugIns oder Modulen herumprobiert kann ich mir vorstellen 
dass man sich z.B. die Joomla-Installation zerschießt und deswegen auf 
einen früheren Stand zurückgehen will.
Wobei man neben der Installation natürlich auch die Datenbank mitsichern 
müsste, die ja den eigentlichen Inhalt beherbergt.

Hat da jemand Erfahrung mit?
Reicht es eher, ab und zu ein BackUp als Snapshot zu machen?
Oder ist Versionsverwaltung im Web eher unüblich?

Viele Grüße,
Schmiedl

von Achim H. (anymouse)


Lesenswert?

Schmiedl schrieb:
> Oder ist Versionsverwaltung im Web eher unüblich?

Generell: Eher weniger

Schmiedl schrieb:
> Als CMS

schon eher. Kommt generell aber auf CMS und Version an.

Nach Suche nach "joomla versioning" findet sich:

"Content versioning is one of the key new features of Joomla 3.2."

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Klar wird auch "Web-Code" versioniert. Für die Daten eines CMS bringt 
dies entweder das CMS mit oder man kann sich mit SQL Dumps behelfen.

von Schmiedl (Gast)


Lesenswert?

Achim Hensel schrieb:
> Schmiedl schrieb:
>> Oder ist Versionsverwaltung im Web eher unüblich?
>
> Generell: Eher weniger
>
> Schmiedl schrieb:
>> Als CMS
>
> schon eher. Kommt generell aber auf CMS und Version an.
>
> Nach Suche nach "joomla versioning" findet sich:
>
> "Content versioning is one of the key new features of Joomla 3.2."

Ok, aber das versioniert ja nur den Content, also den Inhalt, der 
wiederum in der Datenbank steckt.

Die CMS-Installation an sich (jetzt mal über den Joomla-Tellerrand 
herausgeblickt) bleibt davon unberührt.
Ergo, zerschieß ich mir die Installation muss ich das CMS neu aufsetzen. 
Dazu gehörert auch das Neuinstallieren aller Erweiterungen.
Außerdem kann es ja vorkommen, dass man gar selbst Hand anlegen muss im 
Code, z.B. weil ein Modul etwas nicht kann oder man einfach nur im .css 
eine Farbe ändert.

Eine CMS-gestützte Webseite besteht doch immer aus Datenbank, Code, 
Bilder etc.

Inwiefern also das eingebaute Versionierungs-Feature nützlich ist, ich 
weiß es nicht.

von Peter II (Gast)


Lesenswert?

Schmiedl schrieb:
> Außerdem kann es ja vorkommen, dass man gar selbst Hand anlegen muss im
> Code, z.B. weil ein Modul etwas nicht kann oder man einfach nur im .css
> eine Farbe ändert.

aber wo ist dann Schluss?

muss die gleiche mysql Version vorhanden sein?
muss der gleiche Kernel vorhanden sind?
Was ist mit libJpg muss auch die Version passen?

Dann ist es doch das einfachste den ganzen Server zu backupen, dann kann 
man im Notfall alles wiederherstellen.

Die Versionierung wird nur für den Inhalt der Webseite verwendet.

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Schmiedl schrieb:
> zerschieß ich mir die Installation

Bei welchem "Produkt" ist das nicht so? Oder Versionierst du die 
Sektoren deiner Festplatte?? Wichtig ist doch nur das man nach so einem 
Event das System wieder aufsetzen kann (z.B. indem man Backups 
einspielt).

Inhaltliche Änderungen (=Content) zu Versionieren macht man dann um 
Änderungen (nach) zuverfolgen. Und deine Änderungen am CSS o.ä. würde 
man doch idealerweise per Plugin lösen und nicht direkt im Produkt.

von Εrnst B. (ernst)


Lesenswert?

Schmiedl schrieb:
> Daheim fürs Hobby nutze ich z.B. git.

Schmiedl schrieb:
> Wobei man neben der Installation natürlich auch die Datenbank mitsichern
> müsste,

Beides Zusammengefasst:

Häng in dein Git einen pre-commit-hook, der ein mysqldump ausführt.
Fertig, bei jedem git commit landet eine frische Datenbank-Kopie in der 
Versionsverwaltung.

Automatisches "restore" (im post-merge hook?) würde ich aber nicht auch 
noch einbauen, das wär mir an der Stelle zu riskant, und oft auch 
unnötig.


http://git-man-page-generator.lokaltog.net/

von Schmiedl (Gast)


Lesenswert?

> aber wo ist dann Schluss?
>
> muss die gleiche mysql Version vorhanden sein?
> muss der gleiche Kernel vorhanden sind?
> Was ist mit libJpg muss auch die Version passen?
>
> Dann ist es doch das einfachste den ganzen Server zu backupen, dann kann
> man im Notfall alles wiederherstellen.
>
> Die Versionierung wird nur für den Inhalt der Webseite verwendet.

Als Faustregel hätt ich mir genommen: alles, was ich per ftp auf meinen 
Webspace übertrage (bzw, was auf meinem Webspace liegt) sollte 
versioniert werden. Denn das alles ist doch notwendig, um einen 
bestimmten Zustand der Seite wiederherzustellen.

Dass mein Hoster dafür sorgt dass der Server mit einem funktionierenden 
Kernel+Apache läuft setz ich implizit mal vorraus.


> Und deine Änderungen am CSS o.ä. würde
> man doch idealerweise per Plugin lösen und nicht direkt im Produkt.

Idealerweise, ja. Manche Templates bieten immerhin verschiedene Presets 
an, da landet dann die Einstellung in der DB. Oft sind diese aber 
eingeschränkt oder garnicht vorhanden, dann muss man doch wieder ans 
.css.

Mir gehts übrigens weniger ums BackUp (ich vertrau da auch wieder auf 
meinen Hoster) sondern um die "Rückgängig machen"-Funktion, wenn man 
sich den Code zerhauen hat, bzw. wenn sich eine Änderung nachträglich 
als schlecht herausstellt, z.B. weil sie unperformant ist.

Versteht mich nicht falsch, ich will nicht klugscheißen. Ich habe nur 
keine Ahnung wie man ein Webprojekt verwaltet. Aber nur das 
Sichern/Versionieren der DB fühlt sich für mich "falsch" an, weils 
eigentlich nicht reicht.

von Peter II (Gast)


Lesenswert?

Schmiedl schrieb:
> Mir gehts übrigens weniger ums BackUp (ich vertrau da auch wieder auf
> meinen Hoster) sondern um die "Rückgängig machen"-Funktion, wenn man
> sich den Code zerhauen hat, bzw. wenn sich eine Änderung nachträglich
> als schlecht herausstellt, z.B. weil sie unperformant ist.

aber genau dafür gibt es backups.


Versionierung wird verwendet um zu schauen wer hat was geändert.

von Schmiedl (Gast)


Lesenswert?

Peter II schrieb:
> Schmiedl schrieb:
>> Mir gehts übrigens weniger ums BackUp (ich vertrau da auch wieder auf
>> meinen Hoster) sondern um die "Rückgängig machen"-Funktion, wenn man
>> sich den Code zerhauen hat, bzw. wenn sich eine Änderung nachträglich
>> als schlecht herausstellt, z.B. weil sie unperformant ist.
>
> aber genau dafür gibt es backups.
>
>
> Versionierung wird verwendet um zu schauen wer hat was geändert.

Seh ich anders.
Ich hatte ursprünglich hier sogar einen langen Text geschrieben, wieso.
Allerdings würde das die Diskussion in die völlig falsche Richtung 
lenken. Wir wollen uns nicht stundenlang über die Feinheiten von BackUps 
und Versionierung unterhalten.

Wie man es letzendlich bezeichnet spielt für die Lösung der Aufgabe 
keine Rolle.

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Schmiedl schrieb:
> Mir gehts übrigens weniger ums BackUp (ich vertrau da auch wieder auf
> meinen Hoster) sondern um die "Rückgängig machen"-Funktion, wenn man
> sich den Code zerhauen hat, bzw. wenn sich eine Änderung nachträglich
> als schlecht herausstellt, z.B. weil sie unperformant ist.

Ja und wer zwingt dich diese Änderungen live auf dem Server zu machen? 
Ändere deine lokale Kopie (auf einem Feature Branch), testen, mergen, 
hochladen... Auf dem Server landet also immer nur dein versionierter 
Stand. Problem gelöst.

Zweiter Fall: Jemand ändert Daten im CMS -> tägliche SQL Dumps oder 
Versionierungsfeature des CMS oder oder oder ... Problem gelöst.

Man muss nicht immer alles mit dem Hammer bearbeiten was wie ein Nagel 
aussieht, man darf große komplexe Probleme auch in Teilaufgaben zerlegen 
und einzeln lösen.

von Schmiedl (Gast)


Lesenswert?

Läubi .. schrieb:
> Schmiedl schrieb:
> Mir gehts übrigens weniger ums BackUp (ich vertrau da auch wieder auf
> meinen Hoster) sondern um die "Rückgängig machen"-Funktion, wenn man
> sich den Code zerhauen hat, bzw. wenn sich eine Änderung nachträglich
> als schlecht herausstellt, z.B. weil sie unperformant ist.
>
> Ja und wer zwingt dich...

Kein Mensch tut das.

Da ich nicht weiß wie ichs am Besten angehe, bzw. welches Vorgehen sich 
in dem Bereich als praktikabel erwiesen hat frag ich nach.
Komisches Gebaren hier von manchen Heinis.

Also Änderungen an der "Installation" grundsätzlich offline erledigen, 
und diese Offlineversion versionieren. Auf dem Server landet immer nur 
ein als funktionierend geltender Stand des Repositorys.
Der Content selbst wird mit CMS Features oder DB-Dumps zusätzlich 
gesichert, evtl. mit in die Versionsverwaltung aufgenommen.

Sollte man noch anstreben die lokale Kopie mit dem Server jmmer synchron 
zu halten?
Dabei denke ich vor allem an Medien wie z.B. Bilder. Diese wird man ja 
in der Regel direkt in die Mediathek, oder was immer das CMS da 
anbietet, aufnehmen und nicht erst lokal ablegen und dann per ftp 
hochladen... ?

Viele Grüße, Schmiedl

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.