# Bug-Fixing von der Live-Website



## RezaScript (10. Feb 2020)

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?


----------



## mihe7 (11. Feb 2020)

RezaScript hat gesagt.:


> Das ist die beste Lösung die mir einfällt, es muss aber definitiv bessere Lösungen geben.


Inwiefern?


----------



## RezaScript (11. Feb 2020)

mihe7 hat gesagt.:


> Inwiefern?


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 (11. Feb 2020)

RezaScript hat gesagt.:


> 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).



RezaScript hat gesagt.:


> 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.



RezaScript hat gesagt.:


> Ausserdem ist diese Methode nicht wirklich automatisiert.


Naja:


RezaScript hat gesagt.:


> 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.


----------



## RezaScript (11. Feb 2020)

Ok super, das hilft mir weiter. Dankeschön!


----------



## abc66 (11. Feb 2020)

RezaScript hat gesagt.:


> Das ist die beste Lösung die mir einfällt, es muss aber definitiv bessere Lösungen geben.





mihe7 hat gesagt.:


> Inwiefern?


Das hab ich mich auch schon gefragt... natürlich wird nicht immer zwischen stage und nicht-stage gewechselt; prinzipiell ist an stage aber nichts auszusetzen.
Zudem gibt es so gut wie keine Fehler, die zwar auf stage, aber nicht lokal auftreten können.

Das Thema ist nutzlos.


----------



## sascha-sphw (12. Feb 2020)

RezaScript hat gesagt.:


> Das Deployment findet unter stage.example.com statt.


Das ist gängige Praxis.



RezaScript hat gesagt.:


> 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.



abc66 hat gesagt.:


> 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.


----------



## abc66 (12. Feb 2020)

sascha-sphw hat gesagt.:


> außer Du hast lokal genau das gleiche Setup wie auf dem Server, was aber meistens nicht der Fall ist


Aha und woher kannst du das so genau ausschließen?


----------



## sascha-sphw (12. Feb 2020)

abc66 hat gesagt.:


> 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


abc66 hat gesagt.:


> Zudem gibt es so gut wie keine Fehler, die zwar auf stage, aber nicht lokal auftreten können.


und dann


abc66 hat gesagt.:


> Aha und woher kannst du das so genau ausschließen?


----------



## mihe7 (13. Feb 2020)

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.


----------



## RezaScript (13. Feb 2020)

mihe7 hat gesagt.:


> 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.


----------



## mihe7 (13. Feb 2020)

Wo siehst Du da eine Sicherheitslücke?


----------



## RezaScript (13. Feb 2020)

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.


----------



## mrBrown (13. Feb 2020)

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.


----------



## mihe7 (13. Feb 2020)

RezaScript hat gesagt.:


> 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.


Bei CORS geht es um Browser-Sicherheit und nicht um Server-Sicherheit


----------



## RezaScript (13. Feb 2020)

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.


----------



## mrBrown (13. Feb 2020)

RezaScript hat gesagt.:


> 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.


----------



## mihe7 (13. Feb 2020)

RezaScript hat gesagt.:


> Naja, es gibt ja einen Grund weshalb Access-Control-Allow-Origin per Default nicht gesetzt ist.


Klar, CORS dient dazu, die Single Origin Policy zu umgehen. Es wäre also völlig widersinnig, hier standardmäßig etwas zu setzen.


----------

