Ankündigung

Einklappen
Keine Ankündigung bisher.

Environments Sinn

Einklappen

Neue Werbung 2019

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

  • 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?

  • #2
    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, …

    Kommentar


    • #3
      Achso, aber da könnte man die config-datei ja auch einfach ändern und die Zugangsdaten anpassen.

      Kommentar


      • #4
        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.

        Kommentar


        • #5
          Verstehe, d.h. es existieren quasi eigene Subsysteme unter developement und productive, die man dann nur aktiviert?

          Kommentar


          • #6
            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.

            Kommentar


            • #7
              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
              https://github.com/Ma27
              Javascript Logic is funny:
              [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

              Kommentar

              Lädt...
              X