Git-Setup

[Gajel]

Ich musste mich jetzt zwangsweise mit dem Thema GIT beschäftigen, da bei uns die Entwicklung eines neuen Shops ansteht. Und diesmal will ich das Ganze mit einer Versionskontrolle angehen bzw. entwickeln. Server-Administration und Entwicklung ist alles kein Thema aber bei GIT stoße ich auf Neuland. Jetzt habe ich mich mal etwas eingelesen und auch schon in der Praxis etwas rumgespielt aber so ganz sicher fühle ich mich noch nicht.

Aktuell haben wir 2 Dedicated-Server. Ein Server dient als Live-Server und der 2te Server als Backup-Lösung mit einer Failover-IP, so dass man innerhalb von paar Sekunden auf den Backup-Server switchen kann. Mysql wird per Cronjob regelmäßig gesynct und für die Daten ist rsync zuständig.

Entwickeln würde ich das ganze gerne lokal. Das heißt Ubuntu VM, dedizierte Ubuntu Maschine oder einfach WAMP bzw. XAMPP. Und hier geht's schon los ... einerseits tendiere ich zu einer standalone Ubuntu Maschine die mehr oder weniger identisch mit den Servern ist ABER andererseits hätte eine Lösung wie WAMP oder XAMPP auch seine Vorteile. Ich bin an einem Rechner zugange und kann das Tool von Bitbucket (Sourcetree) nutzen.

Aber mal davon ab wollte ich nachfragen ob mein GIT-Setup, so wie ich es mir vorstelle praktikabel und vernünftig ist.

Der lokale httpdocs Ordner (mal unabhängig davon ob Ubuntu-Maschine oder WAMP) wäre mein Arbeitsverzeichnis, von wo ich aus arbeite und commite. Bei Bitbucket lege ich ein repository an und dazu 2 branches (live und beta z.B.). Auf dem Live-Server laufen 2 Domains. Die Live-Domain für die Öffentlichkeit und irgend eine Domain für die Beta-Tests.

Nun weise ich der Live-Domain/Shop den live-branch zu und der Test-Domain den beta-branch. Sagen wir nun ich hab an der order.php Datei gearbeitet und möchte diese fertige Änderungen nun live bringen. Dann würde ich die Änderungen zum beta-branch commiten und schauen (Test-Domain) ob alles auf dem Live-Server läuft.

Jetzt gehen wir davon aus das es keine Probleme gibt. Commite und pushe ich nun am besten die Änderungen direkt vom Arbeitsverzeichnis in den live-branch oder sollte ich an dieser Stelle die Änderungen vom beta-branch zum live-branch pushen? Was wäre hier die richtige Vorgehensweise?

Sehe ich das richtig das mein lokales Arbeitsverzeichnis "völlig" unabhängig von den branches agiert, außer ich pulle was vom live- oder beta branch?!

Den Backup-Server würde ich wieder auf die alte Tour mit Cronjobs und rsync auf stand halten. Oder macht es hier auch sinn mit GIT zu arbeiten?

Also kurz zusammengefasst würde es so aussehen:

• Live-Server mit 2 Domains (meinshop.de und beta.meinshop.de).
• meinshop.de = live-branch Inhalt
• beta.meinshop.de = beta-branch Inhalt
• Lokales Arbeitsverzeichnis zum entwickeln.

Wir ihr seht, habe ich noch paar Fragezeichen über dem Kopf und hoffe das ich sie bald los werde ...

 

[dermoritz]

Was die Frage der Branches betrifft würde ich auf "Git Flow" (einfach googlen, source tree unterstützt es direkt) setzen:
- du arbeitest immer auf dem "develop" Branch
-- von hier machst du falls nötig feature branches
-- checked man develop aus hat man immer den aktuellsten Stand

- releases geschehen immer auf dem "master" branch.
-- Checked man master aus hat man immer den aktuellen release-Stand
-- releases werden getagged (1.0, 1.1 ...)
-- hotfixes macht man auf master

(wie gesagt source tree hat da direkte unterstützung "starte release", "beende release" usw.)

Das repository sollte nur reinen code enthalten, dinge die völlig unabhängig von der Umgebung sind.
Jeder Entwickler kann es auschecken und es läuft (z.B. sobald er es in das httpdocs schiebt oder was auch immer der Entwickler konfiguriert hat ).

Für alles was du später unabhängig releasen willst (wo prinzipiell irgendwann versionen auseinander laufen können) solltest du ein Repository anlegen.

Konfigurationen für verschiedene Umgebungen kann man auch in Git halten, solten aber Strikt getrennt vom Code werden.
Auch Datenbakskripte die einem eine DB inkl. Inhalt (oder nur das Schema) aufsetzen kann man Versionieren - auch getrennt vom Code.

Z.b. Software Version 1.5 braucht Datenbank version 1.0 und Config 1.1

 

[snaxilian]

Jain, besser ist es, du hast zu Beginn nur dein Repo mit dem Branch master. Jetzt willst du eine Änderung machen, dann erstellst du einen Branch testing. Dort machst deine Änderungen in testing und lässt dann z.B. den Code durch ein Test & Build Tool deiner Wahl erstellen. Sind die Änderungen erfolgreich getestet und alles ist so, wie es sein soll, dann machst du einen merge deiner zwei Branches master und testing zum "neuen" master.
Willst du paar Tage später die nächste Änderung machen, erzeugst du wieder einen neuen branch testing_2. Anpassen, testen, deployen, mergen.

Direkt ein git Repo sollte nie direkt das htdocs sein. Git ist und bleibt ein Tool zum versionieren. Älterer Artikel aber gilt immer noch (und war einfach der erste, den ich fand): https://www.golem.de/news/websicherheit-riskante-git-verzeichnisse-1507-115476.html

Git ist nur ein Baustein im Bereich CI/CD. Dazu gehört eben auch ggf. automatische Tests, Builds und dann eben Deployment. Du brauchst also einen reproduzierbaren Prozess von create branch, testing, building, deployment (on beta.domain.tld).

Zu deinem Eingangstext: WAMP/XAMPP ist eine selten schlechte Idee. Dies dient nur dazu für eine stumpfe quick and very dirty Testumgebung und ist extremst unsicher. Development/Test/QA/Prod sollten immer identisch aufgebaut sein denn sonst kann $Entwickler Probleme u.U. nicht nachvollziehen. Wenn mit XAMPP entwickelt wird passiert folgendes: Works on dev machine > ship it > crashed in prod > dev blames ops/customer. Sei es weil die DB (hoffentlich) nicht auf dem gleichen System läuft wie der Webserver oder der (öffentlich erreichbare?) Webserver mal die ein oder andere Absicherung und Härtungsmaßnahme erfahren hat oder ein Apache-Modul nicht oder in anderer Version vorliegt etc.

 

[Yuuri]

Du kannst dir mal git flow ansehen, was sich eigentlich als die Empfehlung durchgesetzt hat. Das kannst du eigentlich als Leitfaden nehmen und daran verstehen, wie (man mit) git arbeitet.

Mehrere Zweige brauchst du nicht, vor allem keine Unterscheidung zwischen live/beta/whatever. Das bringt nur mehr Probleme als sie lösen. Du entwickelst an einer Webseite, kein Plugin oder sonstwas, wo du mehrere Versionen im Support halten musst. Eine Webseite ist ein fertiger Stand, was Anderes gibts dort nicht. Heißt: du nutzt den master Zweig. Kleinere Aufgaben erledigst du direkt darin. Größere Sachen, die evtl. erst durch jemanden/mehrere durchgeprüft/abgesegnet werden müssen, steckst du dabei in einen eigenen Zweig.

Zusätzlich hast du Tags, womit du fixe Stände ggf. markieren kannst. Diese kannst du natürlich auch auschecken statt Zweigen oder Commits.

Im Live-System hast du dann den master ausgecheckt und updatest nur via git pull --ff-only (wenn du mit git deployst). So wird nur der Stand angehoben, wenn ein Fast Forward Merge geschehen kann (es ergo keine Probleme mit Konflikten bei Updates gibt).

Mergen solltest du gleich lassen, eher via Rebase eine lineare History forcieren. Commits können auch immer wieder auf den master gerebased werden, sodass sie auf dem aktuellsten Stand sind. Das Gute beim Rebase: Du kannst u.a. Commits zusammenfügen (squashen), so erhälst du nochmal eine bessere Übersicht, wenn statt 20 Commits ein Feature in einem gesammelt werden kann. Allerdings, wenn du mit mehreren Leuten daran arbeitest, solltest du keinen gepushten Zweig rebasen. Wenn doch, dann vorher Bescheid sagen und abklären.

Im Beta-System machst du es genauso, ist ja schließlich der gleiche Code der laufen soll. Soll irgendwas anders laufen, löse das über Umgebungsvariablen (siehe .env Dateien). Dort kannst du aber natürlich wild auschecken wie du lustig bist - dazu ist es ja da.

Du könntest natürlich auch auf eine CI Pipeline setzen, aber das ist dann nochmal ein anderes Kaliber. Da sollten dann auch Tests u.ä. für alles Mögliche vorhanden sein. Ein einfaches, auch automatisches Deployment, kann man mit Hooks auch hinbekommen.

Eine Sache aber: Wenn du via git deployst, dann nie das Verzeichnis direkt. Erstell einen Unterordner public/web/www/shop oder irgend ein anderer Name. Siehe dazu bspw. die Symfony Verzeichnisstruktur.

In Bitbucket solltest du dann auch regen Einsatz von Issues machen und diese in den Commit-Beschreibungen verlinken, sonst quellen die Commit-Beschreibungen irgendwann über und du findest nichts mehr wieder.

Zur Entwicklung: Lies dich in Docker ein. Gibt imho nichts besseres. Nen Apache starten? docker run httpd:2.4 MySQL? docker run mysql:5.7 Das Schöne daran ist auch, dass du das direkt 1:1 auf dem Server deployen kannst wenn gewünscht. Du kannst also 1:1 mit der selben Konfiguration arbeiten, wie sie dann in Production läuft. Hier solltest du dich aber am besten sofort in Dockerfiles einlesen, denn nur die bringen dir die nötige Flexibilität. Fertige Container sind relativ starr und nur durch Volumes anpassbar, was aber nicht immer ausreichen muss.

 

[r15ch13]

Ich verwende diese Deploy-Methode https://www.digitalocean.com/commun...t-up-automatic-deployment-with-git-with-a-vps
Damit wird auch das Problem mit .git Verzeichnis im httpdocs behoben (Siehe Link von snaxilian)

 

[Gajel]

Vielen dank für die ganzen Antworten. Ich werde mir die Sachen durchlesen und spätestens morgen was dazu schreiben. Bin heute nach dem Fitness kaputt und jetzt muss ich auch noch was kochen...

 

[snaxilian]

Zur Entwicklung: Lies dich in Docker ein. Gibt imho nichts besseres. Nen Apache starten? docker run httpd:2.4 MySQL? docker run mysql:5.7 Das Schöne daran ist auch, dass du das direkt 1:1 auf dem Server deployen kannst wenn gewünscht. Du kannst also 1:1 mit der selben Konfiguration arbeiten, wie sie dann in Production läuft. Hier solltest du dich aber am besten sofort in Dockerfiles einlesen, denn nur die bringen dir die nötige Flexibilität. Fertige Container sind relativ starr und nur durch Volumes anpassbar, was aber nicht immer ausreichen muss.

Gut, wenn jetzt jemand anderes mit Docker anfängt bin ich nicht der böse^^
Ja, der große tolle Vorteil ist die Reproduzierbarkeit und Migrationsfähigkeit von System A zu System B. Ach ne warte das ist keine neue Erfindung, hieß früher nur einfach "hier-ist-unser-VMware/HyperV/Xen-Template", jetzt spart man sich nur den OS-Overhead, setzt aber einen Dockerhost voraus und selbst dann ist selten sichergestellt, dass alles so klappt wie es soll sobald man es sauber machen will und z.B. per docker-compose seine Services voneinander trennt. Setzt der Dev compose in '3' ein, Kunde aber '2' dann kann es schon schief gehen.
Docker hat enorm viele Vorteile, wie z.B. die Skalierbarkeit, "erzwungene" Trennung von Applikation und Nutzdaten, Reproduzierbarkeit (in gewissem Maße eben) aber Security/Hardening bleibt einem trotzdem nicht erspart, Backups sind manchmal so eine Sache (in größeren heterogenen Umgebungen) und ja, ein einzelner Webservice startet schnell, auch die passende DB dazu aber jetzt kommen so ketzerische Leute wie ich und werfen Separierung via docker networks ein oder aktive Nutzung der cgroups, nen vernünftigen Reverse Proxy + WAF etc und schon geht manches auch nicht mehr, was in der grünen Wiese beim Dev ging.
Ich verwende selbst Docker und nun ja... 50% von DevOps sind nun einmal auch die OPS, die sich viele Devs nicht eingestehen wollen und gern anfangs ignorieren
Aber wir schweifen langsam ab und diese Fachsimpelei hilft dem TE glaube ich weniger bzgl. seinen Git-Fragen^^

 

[Yuuri]

@snaxilian

Natürlich ist Docker kein Allheilmittel, aber es vereinfacht Vieles ungemein. Spätestens mit mehreren Entwicklern sieht man enorme Vorteile.

XAMPP (ganz ganz früher) kann man vergessen. Eine VM ging mir extrem auf den Sack, weil man permanent mit VHosts jonglieren musste, damit man auch ja aufs richtige Projekt kommt... Weiterhin muss man sich dort auch um ein vollkommen eigenes OS kümmern. Mehrere MySQL Server installieren, weil man unterschiedliche Versionen für Projekte nutzen muss? Super... Mehrere VMs? Den Scheiß muss ich auch warten, multipliziert mit der Anzahl Projekten.

Das ist das Schöne an Docker. Mich interessieren die Anwendungen, nicht der Unterbau und erst recht nicht muss ich mich um das OS dahinter kümmern oder diese updaten, up- oder downgraden für Tests oder Pakete fixieren oder oder oder...

aber Security/Hardening bleibt einem trotzdem nicht erspart

Sagt ja keiner und nur weil es im Container läuft, heißt es ja nicht, dass da nichts passieren kann. Die entsprechende Anwendung ist ja genauso anfällig und auch Docker hat irgendwo Lücken. Aus ner VM kann man natürlich auch ausbrechen... Ist alles nicht niet- und nagelfest.

aber jetzt kommen so ketzerische Leute wie ich und werfen Separierung via docker networks ein oder aktive Nutzung der cgroups, nen vernünftigen Reverse Proxy + WAF etc und schon geht manches auch nicht mehr, was in der grünen Wiese beim Dev ging.

Sollte man sich vorher einigen/nachfragen oder nachdem der Prototyp steht dementsprechend anpassen.

Aber wir schweifen langsam ab und diese Fachsimpelei hilft dem TE glaube ich weniger bzgl. seinen Git-Fragen^^

Wieso? Er will doch auch was übers Deployment wissen und es ist doch schön, wenn man gleich nen "kleinen" Einblick in die Thematik bekommt. Und wenn es nur aus Stichworten besteht, aber dann weiß er, mit was er sich beschäftigen kann/muss.

"Notfalls" kann man den Server auch typisch bare-metal lassen und ohne Docker deployen. Man ist ja zu nichts gezwungen und wenn einem das besser gefällt... Wieso nicht? Die Vorteile beim Entwickeln sind ja trotzdem nicht weg.

Mach ich ja auch nicht anders. Einiges läuft bare-metal, manche Projekte in einer VM und neuere deploye ich per Docker. Läuft genauso problemlos.

Gitlab läuft bei mir bspw. in einer eigenen VM (via Omnibus Package). Hab jetzt mal eins via Docker zum Laufen gebracht... Ist natürlich bedeutend einfacher und handlicher. Aber so lange meine Instanz läuft, denke ich nicht dran was zu ändern. Der Aufwand steht in keinem Verhältnis.

 

[snaxilian]

Das ist das Schöne an Docker. Mich interessieren die Anwendungen, nicht der Unterbau und erst recht nicht muss ich mich um das OS dahinter kümmern oder diese updaten, up- oder downgraden für Tests oder Pakete fixieren oder oder oder...

Sagt ja keiner und nur weil es im Container läuft, heißt es ja nicht, dass da nichts passieren kann. Die entsprechende Anwendung ist ja genauso anfällig und auch Docker hat irgendwo Lücken. Aus ner VM kann man natürlich auch ausbrechen... Ist alles nicht niet- und nagelfest.

Dann schau mal in die Dockerfiles rein. Auch die basieren auf irgendwelche Distributionen und auf Paketen und entweder hat der Ersteller feste Versionsnummern genutzt (Bugs & Fehler werden so nicht gefixt) oder er nimmt stets latest (stets aktuell aber nur zum jetzigen Zeitpunkt reproduzierbar, da zwischen jetzt und vor einem Jahr die Pakete unten drunter anders sein können). Dann bleibt also wieder nur entweder die Dockerfiles und Images selbst zu pflegen, sprich eigenes Docker-Repo in der Firma oder auf Gedeih und Verderb die Images ausm Docker Store verwenden oder die Enterprise Edition des Store nutzen und nur geprüfte Images nutzen.

 

[Yuuri]

Naja, wenn der Dev schon zu blöd ist... Ich erinnere nur an Windows 8.1 sorgt für Maus-Lags in Spielen. Da haben sie die falsche API verwendet. Das ist nun aber kein Problem von Docker, sondern einfach von... nicht hinterfragenden Devs. Um es nett auszudrücken.