Bug-Fixing von der Live-Website

Diskutiere Bug-Fixing von der Live-Website im Deployment Bereich.
R

RezaScript

Hallo,

ich habe eine Website entwickelt und die funktioniert lokal ziemlich gut. Nur weil sie lokal funktioniert, heisst es aber noch lange nicht, dass sie auch live gut funktioniert. Da könnte es zu ganz vielen Fehlermeldungen wie u.a. Cors Policy geben. Ich möchte an diesen Bugs arbeiten, möchte aber nicht, dass der Benutzer von der Baustelle etwas mitbekommt. Die neue Version der Website soll also erst online sein, wenn alle Bugs behoben sind und die Website auch gründlich getestet wurde.

Was gibt es für professionelle Lösungen um so etwas zu machen?

Was mir so spontan einfällt ist folgendes:
Die Website läuft unter example.com. Das Deployment findet unter stage.example.com statt. Insofern auf stage.example.com alle Bugs gefixed wurden, wird die Domain example.com auf stage.example.com umgeleitet. Bei der nächsten Version findet das Deployment auf example.com statt und falls alles OK ist, wird die Domain stage.example.com wieder auf example.com umgeleitet usw. Das ist die beste Lösung die mir einfällt, es muss aber definitiv bessere Lösungen geben. Wie würdet ihr es machen oder wie machen es denn die grossen Websites?
 
R

RezaScript

Ich weiss nicht aber ich denke nicht, dass das die beste Lösung ist, da es sich bei der einen Website um die Haupt-Domain handelt und bei der anderen Website um eine Sub-Domain. Falls es deswegen aus irgendwelchen Gründen Komplikationen geben wird, möchte ich jetzt schon wissen, ob es bessere Möglichkeiten gibt. Ausserdem ist diese Methode nicht wirklich automatisiert. Ich müsste also dauernd nicht nur den Switch machen, sondern es darf nur eine Website darf aktiv sein und von den Suchmaschinen gefunden werden. Deswegen interessiert es mich, ob es klügere Wege gibt.
 
mihe7

mihe7

Ich weiss nicht aber ich denke nicht, dass das die beste Lösung ist, da es sich bei der einen Website um die Haupt-Domain handelt und bei der anderen Website um eine Sub-Domain. Falls es deswegen aus irgendwelchen Gründen Komplikationen geben wird, möchte ich jetzt schon wissen, ob es bessere Möglichkeiten gibt.
Du kannst natürlich auch auf einer lokalen Maschine so tun, als ob es die Hauptdomain wäre (z. B. über die Hosts-Datei).

sondern es darf nur eine Website darf aktiv sein und von den Suchmaschinen gefunden werden.
Die Domain, die der Besucher erhält, entspricht natürlich immer der produktiven Seite. Nur intern wird geswitched. Was von Suchmaschinen gefunden wird, hängt ja in erster Linie von den Links ab. Verlinkt nichts auf die Testseite, wird diese auch nicht gefunden.

Ausserdem ist diese Methode nicht wirklich automatisiert.
Naja:
Die neue Version der Website soll also erst online sein, wenn alle Bugs behoben sind und die Website auch gründlich getestet wurde.
Abgesehen davon, kannst Du den Spaß natürlich automatisieren. Von einem einfachen Shell-Skript angefangen bis zur Pipeline im CI-Server ist ja alles möglich.
 
A

abc66

sascha-sphw

sascha-sphw

Das Deployment findet unter stage.example.com statt.
Das ist gängige Praxis.

wird die Domain example.com auf stage.example.com umgeleitet.
Stage bleibt Stage und Live bleibt Live! Domains umleiten würde ich nicht. Wenn, dann kannst Du intern über den z.B. Apache auf einen anderen Port leiten. Extern sollte aber alles gleich bleiben.

Zudem gibt es so gut wie keine Fehler, die zwar auf stage, aber nicht lokal auftreten können.
Das kann ganz schnell passieren, außer Du hast lokal genau das gleiche Setup wie auf dem Server, was aber meistens nicht der Fall ist.
 
sascha-sphw

sascha-sphw

Aha und woher kannst du das so genau ausschließen?
100% ausschließen kann man das nicht. Aber die Chancen stehen gut wenn das Setup identisch ist.

Aber mal ganz Ehrlich... Du kannst Dich auch nicht entscheiden.
erst
Zudem gibt es so gut wie keine Fehler, die zwar auf stage, aber nicht lokal auftreten können.
und dann
Aha und woher kannst du das so genau ausschließen?
 
mihe7

mihe7

Man kann die Stage auch als Test bzgl. der Domain-Unabhängigkeit betrachten - wenn es lokal und über die Stage-Domain läuft, dann stehen die Chancen gut.
 
R

RezaScript

Du kannst natürlich auch auf einer lokalen Maschine so tun, als ob es die Hauptdomain wäre (z. B. über die Hosts-Datei).
Nur so aus Neugier ... wie sieht es denn dann mit CORS Policy aus? Ist das Verhalten dann genau gleich wie die reale Domain oder gibt es dann Fehlermeldungen? Ich nehme an, dass es zur Fehlermeldungen führt, ansonsten sehe ich hier eine Sicherheitslücke.
 
R

RezaScript

Naja, lokal könnte ich z.B. die Daten einer beliebigen Website abrufen, sie in meiner Datenbank speichern und sie anschliessend für meine eigene Website verwenden.
 
M

mrBrown

Wenn die Wensite die Daten bereit stellt kommst du da so oder so dran.

Aber eine fremde Website kannst du natürlich nicht einfach lokal laufen lassen, außer wenn du alle Seiten erst speicherst - aber dann hast du lokal eben nur den Content, auf den du sowieso Zugriff hast.
 
R

RezaScript

Naja, es gibt ja einen Grund weshalb Access-Control-Allow-Origin per Default nicht gesetzt ist. Ich kann mir deshalb nicht vorstellen, dass der Server auf einen Request vom localhost genau gleich reagiert wie auf einem Request von der eigenen Domain. Ich hab das grad nicht getestet aber ich denke die Headers müssten anders sein.
 
M

mrBrown

Naja, es gibt ja einen Grund weshalb Access-Control-Allow-Origin per Default nicht gesetzt ist. Ich kann mir deshalb nicht vorstellen, dass der Server auf einen Request vom localhost genau gleich reagiert wie auf einem Request von der eigenen Domain. Ich hab das grad nicht getestet aber ich denke die Headers müssten anders sein.
Nein, wenn das über die Host-Datei konfiguriert wird, sieht das für den Browser wie ein Remote-Zugriff aus und der Server verhält sich eh immer gleich.
 
Thema: 

Bug-Fixing von der Live-Website

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben