Ankündigung

Einklappen
Keine Ankündigung bisher.

local - testing - live System

Einklappen

Neue Werbung 2019

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

  • local - testing - live System

    Hallo @all,

    ich programmiere seit einiger Zeit mit PHP eine Webseite, bzw. eher ein Webservice. Ich programmiere local (mit Xampp + Netbeans), wenn ich eine "laufende" Version habe - oder etwas mit E-Mail versenden teste (das geht local nicht) - lade ich das, was ich habe auf einen testing-Webspace. Dafür muss ich an einigen Stellen rumschrauben, die .htacces muss geändert werden. In Settings.php muss einige Konstanten umgestellt werden, die db-Daten müssen geändert werden. Und dann sind da noch einige Verzeichnisse, welche ich (online) behalten, bzw. nicht überschreiben möchte. Dafür will ich alle lokalen *.svn Dateien/Ordner nicht uploaden ...

    Es ist also ziemlich chaotisch, ich habe mittlerweile eine Liste, was ich vor dem Upload alles machen muss. Das Behalten der Verzeichnisse mache ich z.B. dadurch, dass ich sie vom testing-Webspace downloade und nach dem Upload der neuen Version wieder uploade. Da es aber zum Teil sehr große Dateien sind und diese mit der Zeit auch mehr werden ist das so Mist. -.-

    Ich hoffe ich habe mein Problam einiger Maßen verständlich ausgedrück und jemand kann mir einen Tipp geben, wie ich das meister - ich habe auch schon daran gedacht mir selber ein kleines Tool zu schreiben, aber ich bin doch nich der einzigste mit dem Problem, oder!?

    mfg
    d0ne

  • #2
    Auf anhieb fällt mir auf das du die Datenbank bei die Lokal nutzt, warum nicht die auf dem Space? So sparst du dir Änderung des Connectionstrings oder du lagerst die conenction in einer weirere php datei aus (besser idee).
    Ansonsten schon einmal überlegt "Live" auf dem Space zu arbeiten? Damit sparst dir den vielen Aufwand von Daten kopieren, etc.
    Look at This!
    Digital-Duty.DE
    Für Syntax-Fehler übernehme ich keine Haftung!

    Kommentar


    • #3
      Zitat von Tholi Beitrag anzeigen
      Auf anhieb fällt mir auf das du die Datenbank bei die Lokal nutzt, warum nicht die auf dem Space?
      Abgesehen davon, dass etliche Hoster das gar nicht erlauben, musst du dann auch entsprechend längere Laufzeiten in Kauf nehmen.
      Zumal sich noch die Frage stellt, ob du deine DB-Zugangsdaten fortwährend unkodiert über's Netz schicken willst.

      Ansonsten schon einmal überlegt "Live" auf dem Space zu arbeiten? Damit sparst dir den vielen Aufwand von Daten kopieren, etc.
      Das ist keine gute Idee.

      Abgesehen davon, dass du jede klitzekleine Änderung, selbst das Ergänzen eines vergessenen Semikolons, erst mal wieder hochladen musst - die potentielle Möglichkeit, beim Testen irgendwas zu zerschiessen, würde ich auch nicht in Kauf nehmen wollen.
      [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

      Kommentar


      • #4
        Zitat von ChrisB Beitrag anzeigen
        Das ist keine gute Idee.

        Abgesehen davon, dass du jede klitzekleine Änderung, selbst das Ergänzen eines vergessenen Semikolons, erst mal wieder hochladen musst - die potentielle Möglichkeit, beim Testen irgendwas zu zerschiessen, würde ich auch nicht in Kauf nehmen wollen.
        Also ich arbeite nur live und das mit einem Dorf dsl 4k Leitung und in dem Moment wo ich vom Speichern auf den Browser wechsel sind die Änderungen schon Online. Zur Sicherung kannst dir doch in bestimmten Abständen Updates ziehen oder eine 2te Version laufen lassen in der du die Änderungen machst und wenn es läufst überspielst.
        Look at This!
        Digital-Duty.DE
        Für Syntax-Fehler übernehme ich keine Haftung!

        Kommentar


        • #5
          Also mit der Server-db nutzeen geht technisch schon nicht, weil der Hoster das nicht erlaubt (ist ja auch sinnvoll). Auch ansonsten will ich nicht mit der db arbeiten, mit der auch unsere Kunden arbeiten. Ein falscher klick und alles ist weg!?

          Zitat von ChrisB Beitrag anzeigen
          beim Testen irgendwas zu zerschießen, würde ich auch nicht in Kauf nehmen wollen.
          Ja, auch das möchte ich nicht riskieren, ein Semikolon vergessen, STRG + S und schon gibt der Server nur noch Errors aus!? - Nein, danke!

          Ich hoffe jemand hat noch einen guten Tipp, wie ich mein Problem "professionell" löse...

          mfg
          d0ne

          Kommentar


          • #6
            Sowas kannst du bei deiner privaten Homepage vielleicht machen, bei gut besuchten Seiten kannst du sowas aber nicht machen. Da kannst du nicht riskieren dass irgendwas kaputt geht und die Seite dann 5 Minuten nur nen Parse Error bringt.

            Kommentar


            • #7
              Dafür hat man eben eine 2te Version liegen, die auch in einem priivaten Bereich auf dem Space liegen kann. Sehe da nicht das Problem an der 2ten Version Live arbeiten zu können und wenn dort alles läuft, die 1te durch die 2te zu ersetzen...
              Look at This!
              Digital-Duty.DE
              Für Syntax-Fehler übernehme ich keine Haftung!

              Kommentar


              • #8
                die 1te durch die 2te zu ersetzen...
                Womit wir wieder bei meinem Ursprungsproblem wären ...

                Kommentar


                • #9
                  Zitat von Tholi Beitrag anzeigen
                  Dafür hat man eben eine 2te Version liegen, die auch in einem priivaten Bereich auf dem Space liegen kann.
                  Definiere „privater Bereich“.

                  Wenn du ausschliessen willst, dass z.B. mal durch eine falsch (zusammen-)gesetzte, beim Löschen von irgendwas verwendete Pfadangabe plötzlich ein „Oopsie“ im Produktivsystem passiert, müsstest du schon einen zweiten Account oder vergleichbares nutzen, so dass PHP gar keinen Zugriff auf diese Daten hat.
                  Für die Datenbank analog.


                  Es bleibt dabei: Auf einem Produktivsystem „testen“ wird niemand, der das ganze halbwegs professionell angehen will.
                  [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

                  Kommentar


                  • #10
                    Das eMail-Problem lässt sich leicht lösen: benutze SMTP.

                    Auf dem Ziel-OS testen macht natürlich dennoch Sinn, insbesondere um Pfad-Probleme zu finden.
                    Am Einfachsten geht das wohl, indem du einen SVN-Checkout in der Testumgebung machst.
                    Da kannst du dir auch feine Scripts basteln, die das automatisieren.
                    Hab ich schon ein paar Mal gemacht, so dass nach jedem Commit automatisch ins Testsystem deployed wird inkl. CodeSniff etc.

                    Was das behalten von Dateien angeht - Stichwort svn:ignore
                    Gerade z.B. für Config-Files handhabe ich das einfach so, dass eine <config.xyz>.default ins SVN kommt und ein svn:ignore auf <config.xyz>.
                    Mache ich einen Checkout (egal ob lokal oder Testumgebung) bekomme ich nur die Default-Datei, die kopiere ich, passe sie an und fertig.
                    Die wird nie überschrieben, da a) nur die Default im SVN ist und b) ein Ignore auf der eigentlichen Datei liegt, was sie beim Committen unberücksichtigt lässt.

                    Zitat von ChrisB Beitrag anzeigen
                    Es bleibt dabei: Auf einem Produktivsystem „testen“ wird niemand, der das ganze halbwegs professionell angehen will.
                    Jein...wenn der Kunde meint "das Testsystem ist noch nicht fertig, mach mal am Livesystem" hat man nicht so viele Optionen
                    VokeIT GmbH & Co. KG - VokeIT-oss @ github

                    Kommentar


                    • #11
                      Zitat von G.Schuster Beitrag anzeigen
                      Auf dem Ziel-OS testen macht natürlich dennoch Sinn, insbesondere um Pfad-Probleme zu finden.
                      Kann man machen, wenn der Rest schon fertig ist.
                      Dass man noch mal „alles“ durchtestet, wenn es auf dem Server ist, bevor man es live schaltet, sollte auch selbstverständlich sein.

                      Jein...wenn der Kunde meint "das Testsystem ist noch nicht fertig, mach mal am Livesystem" hat man nicht so viele Optionen
                      Wenn er vorher schriftlich zusichert, die Verantwortung für alle sich ggf. daraus ergebenden Probleme zu übernehmen - meinetwegen.
                      [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

                      Kommentar


                      • #12
                        Zitat von ChrisB Beitrag anzeigen
                        Kann man machen, wenn der Rest schon fertig ist.
                        Dass man noch mal „alles“ durchtestet, wenn es auf dem Server ist, bevor man es live schaltet, sollte auch selbstverständlich sein.
                        Für solche dinge hat man dann hoffentlich automatisierte tests (phpunit, selenium, ... ) ... weil bei jeder änderung/deployment alles händisch wieder testen ... ieehh
                        [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
                        | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

                        Kommentar


                        • #13
                          Zitat von G.Schuster Beitrag anzeigen
                          Das eMail-Problem lässt sich leicht lösen: benutze SMTP.
                          Wie kann ich dadurch das Problem lösen? Ich benutze mail() und "das Problem" ist, dass lokal zwar so getan wird, als ob die E-Mail geschickt wird, diese aber nicht wirklich gesendet wird. So kann ich nicht überprüfen ob die E-Mail wirklich so wie gewünscht versendet wird ... Und wie würde SMPT mein Problem lösen!?

                          Zitat von G.Schuster Beitrag anzeigen
                          Auf dem Ziel-OS testen macht natürlich dennoch Sinn, insbesondere um Pfad-Probleme zu finden.
                          Ja, ich bleibe auch dabei, dass es so sinnvoller ist. Bei uns kommt noch hinzu, dass die Webseite/der Webservice nicht nur von mir getestet wird, sondern meine Scripte müssen mit einem (C++ ) Klienten kommunizieren. Wenn jetzt irgendetwas an der Kommunikation geändert wird, soll das natürlich nicht erst beim live-Betrieb getestet werden.

                          Zitat von G.Schuster Beitrag anzeigen
                          Am Einfachsten geht das wohl, indem du einen SVN-Checkout in der Testumgebung machst.
                          Da kannst du dir auch feine Scripts basteln, die das automatisieren.
                          Hab ich schon ein paar Mal gemacht, so dass nach jedem Commit automatisch ins Testsystem deployed wird inkl. CodeSniff etc.
                          Mh, hört sich gut an, hast du da vll. 'nen Link bzw. ein paar Stichworte zum googeln!?

                          Zitat von G.Schuster Beitrag anzeigen
                          Was das behalten von Dateien angeht - Stichwort svn:ignore
                          Gerade z.B. für Config-Files handhabe ich das einfach so, dass eine <config.xyz>.default ins SVN kommt und ein svn:ignore auf <config.xyz>.
                          Mache ich einen Checkout (egal ob lokal oder Testumgebung) bekomme ich nur die Default-Datei, die kopiere ich, passe sie an und fertig.
                          Die wird nie überschrieben, da a) nur die Default im SVN ist und b) ein Ignore auf der eigentlichen Datei liegt, was sie beim Committen unberücksichtigt lässt.
                          Mh, joa, aber mein eigentliches Problem ist nicht, dass ich bestimmte Dateien nichts ins SVN-Rep haben möchte, sondern dass ich sie beim hochladen - perFTP - nicht überschreibe.
                          Ich habe dann lokal einen Ordner "ProjektName" und auf dem Server einen Ordner "ProjektName" (Der Ordner ist auf dem Server irgendwie per DNS oder ähnlich so konfiguriert, dass er über ProjektName.de erreichbar ist).
                          Jetzt habe ich das bis jetzt so gemacht, dass ich den lokalen "ProjektName"-Ordner nach "ProjektName_Upload" kopiert habe, in "ProjektName_Upload" ale Configs etc. geändert habe und dann diesen Ordner hoch geladen habe. Per FTP habe ich dann den "alten" Server-Ordner umbenannt "ProjektName.DATUM.bck" und denn "ProjektName_Upload" in "ProjektName". Fertig war der Upload, und jetzt ist es aber so, dass ich in dem Server-Ordner einige Ordner/Dateien habe, die ich nicht überschreiben/ bzw. "verschwinden" lassen möchte. ...

                          Ich glaube ziemlich verwirrend, hoffentlich wird jemand d'raus schlau...

                          Zitat von robo47 Beitrag anzeigen
                          Für solche dinge hat man dann hoffentlich automatisierte tests (phpunit, selenium, ... ) ... weil bei jeder änderung/deployment alles händisch wieder testen ... ieehh
                          Ich sehe schon, ich kann mich nicht länger um solche Test drücken. -.-
                          Aber zB. habe ich in der lokalen .htacces einige Pfade stehen, die auf dem Server anders sind - das muss ich doch a) per Hand ändern und b) manuell testen - oder!?


                          mfg
                          d0ne

                          Kommentar


                          • #14
                            Zitat von d0ne Beitrag anzeigen
                            Wie kann ich dadurch das Problem lösen?
                            ...
                            Und wie würde SMPT mein Problem lösen!?
                            SMTP löst dein Problem in sofern, dass der Versand auch wirklich ausgeführt wird.
                            mail() ist nicht grade der Brüller, insbesondere wenn man komplexere Mails versenden möchte oder eben auf Windows angewiesen ist.

                            Zitat von d0ne Beitrag anzeigen
                            Mh, hört sich gut an, hast du da vll. 'nen Link bzw. ein paar Stichworte zum googeln!?
                            Nicht wirklich.
                            Schau dich einfach mal auf subversion.apache.org um, wenn mich nicht alles täuscht müssten die auch die ganzen Contributed Scripts von Tigris übernommen haben.
                            Ich hab sowas bisher immer selbst gebaut, daher kann ich dir da nicht mit sonderlich viel Hilfe dienen.

                            Zitat von d0ne Beitrag anzeigen
                            Mh, joa, aber mein eigentliches Problem ist nicht, dass ich bestimmte Dateien nichts ins SVN-Rep haben möchte, sondern dass ich sie beim hochladen - perFTP - nicht überschreibe.
                            Deshalb der Checkout aufs Zielsystem.
                            Hast du z.B. einen Upload-Ordner, der ja zwangsläufig unterschiedliche Inhalte haben wird, setze ein svn:ignore - et voila, die Inhalte bleiben unberührt und trotzdem kannst du ein einfaches "svn up" für das Gesamtprojekt machen.
                            Gleiches gilt für meinen Tipp mit den Default-Configs.
                            Die "Richtigen" werden nie überschrieben, müssen also auch nicht jedes Mal neu angepasst werden.
                            Lediglich wenn du die Default-Config änderst musst du einmalig die Änderungen nachziehen.
                            VokeIT GmbH & Co. KG - VokeIT-oss @ github

                            Kommentar


                            • #15
                              Zitat von G.Schuster Beitrag anzeigen
                              mail() ist nicht grade der Brüller, insbesondere wenn man komplexere Mails versenden möchte oder eben auf Windows angewiesen ist.
                              Naja, bis jetzt reicht mir mail()und so schlimm finde ich das mit dem E-Mail senden auch nicht - auf jeden Fall kein Punkt, für den in in den nächsten Tagen Zeit habe!

                              Zitat von G.Schuster Beitrag anzeigen
                              Ich hab sowas bisher immer selbst gebaut, daher kann ich dir da nicht mit sonderlich viel Hilfe dienen.
                              Aber wenn du es doch selber gemacht hast, solltest du doch wissen, wie es geht - oder!?

                              Zitat von G.Schuster Beitrag anzeigen
                              Deshalb der Checkout aufs Zielsystem.
                              Hast du z.B. einen Upload-Ordner, der ja zwangsläufig unterschiedliche Inhalte haben wird, setze ein svn:ignore - et voila, die Inhalte bleiben unberührt und trotzdem kannst du ein einfaches "svn up" für das Gesamtprojekt machen.
                              Mh, sry ich habe einfach noch nicht so viel Erfahrung mit SVN ...
                              Aber "svn up" kann ich doch nur machen, wenn der Ordner auf dem Webspace ein Repositorium ist, oder nicht!?
                              Der ORdner auf dem Webspace ist ein ganz normales Verzeichnis mit "ein paar" Scripten drin -das Verzeichnis hat mit SVN doch gar nichts zu tun!?

                              mfg
                              d0ne

                              Kommentar

                              Lädt...
                              X