Best Practice für Produktions- und Testumgebungen in Google App Engin

8

Was sind die besten Vorgehensweisen für Produktions- und Testumgebungen in Google App Engine? Ist es eine gute Idee, separate Projekte einzurichten?

Wir verwenden auch Google Cloud Storage und Cloud SQL. Ich möchte Unfälle vermeiden, bei denen jemand fälschlicherweise in der Produktion arbeitet, wenn er im Test arbeiten will.

Wir werden viel Material in GCS speichern. Aus meiner Sicht sind GCS-Umgebungen zwischen Projekten getrennt. Dies kann für uns wünschenswert sein. Aber wenn wir das Produkt zum Testen kopieren möchten, ist es möglich, GCS von einer App zur anderen zu kopieren?

Ich freue mich darauf zu hören, wie andere das machen.

    
Mike Dee 13.10.2014, 00:12
quelle

2 Antworten

4

Bruyere's Antwort ist technisch richtig, Sie können entweder Ihre App versionieren oder separate Projekte verwenden.

In der Praxis habe ich beides gemacht und Sie müssen die Projekte aus vielen guten Gründen immer wieder trennen:

  • Sie möchten vielleicht nicht, dass die gleichen Leute die Rechte haben, das Staging-Env zu aktualisieren (alle Devs hätten diese Fähigkeit zum Beispiel) und das Produktions-Env (normalerweise wäre dies auf den Tech-Lead oder das QA-Team beschränkt) Sie Continuous Integration Server)
  • Die Isolierung von zwei Versionen der App-Engine ist nicht so einfach, insbesondere wenn Sie mit Cron-Jobs, E-Mail oder XMPP-Empfang arbeiten.
  • Sie möchten möglicherweise nicht, dass dieselben Personen die Staging-Daten und die Prod-Daten lesen / schreiben können
  • Sie möchten sicherstellen, dass die App Engine-Prod-App nicht in den Cloud Storage-Bucket-Bucket schreibt. Wenn sie Teil desselben Projekts sind, ist dies standardmäßig möglich

Ich empfehle, die umweltbezogenen Daten (Cloud-Speicher-Bucket, Cloud SQL-URL usw.) in einer Konfigurationsdatei zu speichern, die von der Anwendung geladen wird. Wenn Sie Java verwenden, verwende ich persönlich eine Eigenschaftendatei, die von Maven anhand von zwei Profilen (dev und prod, wobei dev der Standard ist) ausgefüllt wird.

Ein weiterer wichtiger Punkt ist die Trennung von Umgebungen von Anfang an. Sobald Sie davon ausgehen, dass beide Umgebungen in der gleichen Anwendung leben, wird ein Großteil Ihres Codes basierend auf dieser Annahme entwickelt und es wird schwieriger, zu zwei verschiedenen Projekten zurückzukehren.

    
David 14.10.2014 01:51
quelle
1

Ich kann zwei Arten sehen, dies zu tun, alles abhängig von Ihren Bedürfnissen:

1) Wenn Sie Versionen in Ihrer App, eine andere Instanz in Cloud SQL und einen anderen Bucket-Namen für GCS verwenden, können Sie dasselbe Projekt verwenden. Sie müssen nur sehr vorsichtig sein, um festzulegen, auf welches Ziel die einzelnen Aufrufe gehen sollen, und sie umleiten, wenn sie live geschaltet wird.

2) Die Verwendung eines separaten Projekts ist wahrscheinlich die sicherere Option, aber Sie müssen auf jeden Fall einen eindeutigen Bucket-Namen verwenden. Bucket-Namen müssen in allen GCS-Instanzen eindeutig sein.

Es ist ziemlich einfach, von einem Eimer zum anderen zu kopieren, sobald Sie Ihre Berechtigungen eingerichtet haben. Mit gsutil können Sie von einem Bucket in einen Bucket kopieren.

    
Ryan 13.10.2014 13:52
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Der effizienteste Weg, mit PHP den vorherigen Buchstaben im Alphabet zu erhalten