Ankündigung

Einklappen
Keine Ankündigung bisher.

Environments Sinn

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Gast-Avatar
    Ein Gast erstellte das Thema Environments Sinn.

    Environments Sinn

    Hallo, ich habe ein paar Frameworks durchforstet und bin desöfterten darauf gestoßen, dass im Code ein Art Modus geschaltet wird zwischen environment und productive. Will heißen, dass ich manchmal variablen namens APP_ENVIRONMENT sehe die einen boolean enthält. Wie ich das oberflächlich beurteilen kann, soll versucht werden zwischen den einzelnen fiktiven Umgebungen zu switchen. Allerdings erschließt sich mir der Sinn dabei nicht so recht. Beinhaltet deren Code vllt Fragmente, die auf diese Modi abgestimmt sind, oder wieso machen die das?

  • Ma27
    antwortet
    nun nehmen wir mal als konkretes Beispiel Symfony2: wenn man den Kernel startet, kann man als Parameter das Environment mitgeben.
    Ich habe in meinem Uebungsprojekt jetzt zwei Einstiegsdateien (eine fuers dev, eine fuers prod): https://github.com/Ma27/SenNetwork/b...eb/app.php#L12, https://github.com/Ma27/SenNetwork/b...pp_dev.php#L23

    Anhand des Environments kann man nun die config dateien anpassen: https://github.com/Ma27/SenNetwork/t...ter/app/config
    So hab ich im Prod den APC Cache fuer Validation und Doctrine Zeugs an: https://github.com/Ma27/SenNetwork/b...rod.yml#L5-L13
    Im Dev ist der Profiler an und die dev routing file wird geladen: https://github.com/Ma27/SenNetwork/b...dev.yml#L6-L13
    Und im test ist der swiftmailer abgeschaltet, damit in den Integration Tests nicht unnoetig emails versendet werden: https://github.com/Ma27/SenNetwork/b...st.yml#L21-L22

    Anhand dieses Beispiel sieht man, dass man diese Environments dazu nutzen kann, die Applikation fuers Development und fuers Prod zu konfigurieren, ohne beim Deploy die Config files (ausnahme die parameters.yml) aendern zu muessen.

    LG

    Einen Kommentar schreiben:


  • mermshaus
    antwortet
    Ich würde das gar nicht so spezifiziert ausdrücken. Es gibt einfach Dinge, die sich zwischen verschiedenen Umgebungen (Entwicklungssystem, Livesystem, …) unterscheiden. Um nicht ständig den Code an zig Stellen verändern zu müssen, wenn er in eine andere Umgebung übertragen wird, kann das Environment-Konzept genutzt werden, das ein unkompliziertes Umschalten ermöglicht.

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    Verstehe, d.h. es existieren quasi eigene Subsysteme unter developement und productive, die man dann nur aktiviert?

    Einen Kommentar schreiben:


  • mermshaus
    antwortet
    Ja, das ist nur umständlich und wird mitunter richtig umständlich, wenn du dann etwa auch noch im Code einen speziellen Event-Logger fürs Debugging irgendwo zuweist oder so. Da ist es auf Dauer einfach komfortabler, das alles an einen Wert zu koppeln, der simpel umzuschalten ist.

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    Achso, aber da könnte man die config-datei ja auch einfach ändern und die Zugangsdaten anpassen.

    Einen Kommentar schreiben:


  • mermshaus
    antwortet
    zwischen environment und productive
    environment=development?

    dass ich manchmal variablen namens APP_ENVIRONMENT sehe die einen boolean enthält
    Variable=Konstante?
    boolean=string?

    Beinhaltet deren Code vllt Fragmente, die auf diese Modi abgestimmt sind, oder wieso machen die das?
    Ein anschauliches Beispiel ist, dass du auf dem Entwicklungsrechner eine andere Konfiguration hast als nachher auf dem Livesystem. Das betrifft etwa Zugangsdaten für Datenbanken oder Mailserver, Fehlerbehandlung (das Livesystem sollte dem Nutzer keine PHP-Fehlermeldungen anzeigen), Debug-Infos, …

    Einen Kommentar schreiben:

Lädt...
X