Partage
  • Partager sur Facebook
  • Partager sur Twitter

Gérer mon projet PHP

avec une version prod et dev

    16 août 2018 à 22:02:34

    Bonsoir à tous,

    J'ai actuellement un projet PHP (sans framework) dont j'ai pris la mauvaise habitude de coder et de mettre à jour les fichiers qui sont directement présents sur le serveur de mon hébergement web (OVH) car pour l'instant peu de personnes ont accès au site.

    J'aimerais mettre en place différentes "bonnes pratiques" pour mon projet :

    • Coder mes nouvelles fonctionnalités en local pour ensuite les transmettre au serveur
    • Avoir un outil de gestion de version avec une branche dév et une branche prod qui si celle-ci est mise à jour, met à jour le code sur le serveur
    • Éviter si possible d'installer des logiciels tierces

    Le scénario idéal serait donc de coder en local le projet en utilisant git (en utilisant mon hébergement comme remote)puis quand le résultat me convient et que tout est stable mettre à jour la branche Prod et en même temps mettre à jour le site hébergé chez OVH

    J'ai trouvé ce tutoriel sur le site d'OVH qui a l'air de correspondre à mon besoin mais il est fait pour le framework Laravel et il ne parle pas de la partie locale car je ne vois pas comment dire si je le code est dans le dossier prod alors ont accède à la BDD présente sur le serveur et qu'il doit utiliser l'URL monsite.com ET si on est dans la partie dév alors on utilise localhost et une BDD locale (mais que se passerait-il si on était plusieurs sur le projet ?).

    Je crois que je me pose trop de questions en même temps et ça m'empêche de trouver une solution ^^

    D'avancer merci pour votre aide

    • Partager sur Facebook
    • Partager sur Twitter
      17 août 2018 à 8:36:04

      Bonjour,

      Les réponses que tu auras m'intéresseront sans doute car je suis un peu dans le même cas que toi, à la différence près que j'utilise depuis longtemps le framework PHP CodeIgniter. Effectivement avec le recul je pense que l'usage d'un framework simplifie considérablement les choses puisqu'au final dans toute la panoplie de fichiers qui le composent, il y a finalement trois paquets différents :

      • Le "système" du framework, qui correspond à un dossier avec de très nombreux fichiers qui "font tourner" le système et que tu n'as jamais besoin de modifier pour faire ton projet. Cela permet aussi de procéder à une mise à jour du framework assez facilement (c'est le seul dossier que tu as à remplacer - le plus souvent - quand une mise à jour du framework lui-même intervient).
      • D'éventuelles librairies complémentaires, qui viennent assurer des tâches bien précises au sein de ton application. C'est pour elles que des outils comme Composer qu'à titre personnel j'utilise depuis très peu de temps sont assez révolutionnaires pour deux raisons. D'une part il suffit d'écrire une "liste de courses" avec la liste de ce dont tu as besoin et tout sera alors téléchargé automatiquement... voire mis à jour si tu le souhaites... D'autre part le chargement de tout ce petit monde est simplifié grâce à un "autoloader" unique qui se charge de tout ouvrir quand il y a besoin.
      • Ton propre code enfin, qui se traduit généralement par des contrôleurs (fichiers PHP correspondant à la logique applicative qui le plus souvent se présente sous la forme de classes et d'une longue suite de méthodes publiques et privées), des modèles (les requêtes qui s'adressent à ta base de données), et les vues (ce qui met en forme tout ça). Au final, quand tu fais évoluer ton application, c'est sans doute le seul morceau qui "évolue" par rapport au reste que tu ne gères pas toi (mise à jour des frameworks) ou que tu ne fais que demander en l'ajoutant à une liste (librairies complémentaires via composer).

      Au final, l'arrivée de nouvelles fonctionnalités de ton site se résume à la mise à jour de ton seul code personnel, et exceptionnellement à l'arrivée de nouvelles librairies dont tu as eu besoin pour te faciliter le travail et qui se fait en ajoutant leur nom et leur version dans une liste que Composer utilise ensuite pour aller récupérer automatiquement les fichiers, les ranger et en prévoir le chargement. On peut ajouter un dernier ingrédient qui serait le fichier de configuration du framework... mais lui aussi ne change pas souvent une fois le projet lancé.

      En tout cas même si tu n'utilises pas un framework, je pense que cette organisation est tout de même à garder en tête puisqu'elle permet des mises à jour spécifiques et "non globales", ce qui permet à ton système de fonctionner quasi sans interruption dans le cas où seul ton propre code est mis à jour ce qui, en général, ne prend que quelques secondes tout au plus, durant lesquels tu peux même jusqu'à aller à désactiver temporairement son système de routes pour afficher une page type "maintenance, nous revenons dans quelques secondes..."

      Voilà pour ce petit apport qui répond évidemment pas à ta question mais qui essaye d'apporter des idées complémentaires ;)

      • Partager sur Facebook
      • Partager sur Twitter
      Nicolas - Développeur PHP qui bricole pas mal, utilisant Bootstrap, Materialize, MySQL et quelques astuces piochées par ci par là. Codeigniter a changé ma vie de codeur :D
        20 août 2018 à 23:54:58

        Bonsoir,

        Merci pour vos réponses. Il semblerait qu'il est grand temps pour moi d'utiliser un Framework pour faire quelque-chose de plus "pro". Je vais donc me lancer avec Symfony et voir ce que ça va donner ^^

        • Partager sur Facebook
        • Partager sur Twitter
          21 août 2018 à 3:15:36

          Salut, tu peux utiliser rsync pour synchroniser tes fichiers.

          Moi je développe la plupart du temps directement sur le serveur. je fais 2 répertoires dev et www. Sur une page, j'ai un bouton qui lance un commande rsync pour synchroniser les 2 répertoires.

          Tu peux aussi synchroniser de local à hébergeur.

          Linux, Synchroniser les fichiers avec rsync

          -
          Edité par Romuald44 21 août 2018 à 3:23:18

          • Partager sur Facebook
          • Partager sur Twitter
            21 août 2018 à 7:06:22

            Pour éviter les mauvais conseils, je te conseil cette vidéo @Romuald44 : https://youtu.be/8O-IeLRgsCI

            Rsync c'est pas un outils pour du déploiement et en plus même si tu travail dans un dossier à part le faire sur le serveur directement c'est pas très propre.

            -
            Edité par quenti77 21 août 2018 à 11:48:14

            • Partager sur Facebook
            • Partager sur Twitter
              21 août 2018 à 9:33:20

              Pour faire du déploiement automatique, il va falloir utiliser des outils d'intégrations continue. Gitlab en propose un nativement sinon tu peux utiliser Jenkins ou autres. Mais tu aura forcément besoin d'outils externe.

              Pour prendre mon exemple, je créé un "build" avec PHING. Ce build dit quoi exécuter sur le serveur : git clone, tests unitaires, etc... Ensuite ce build est lancé, soit manuellement, soit automatiquement avec un outil d'intégration continue tel jenkins (pas évident à configurer). Regarde du côté de Gitlab CI qui peut être pas mal.

              • Partager sur Facebook
              • Partager sur Twitter

              Pensez à mettre vos sujets en résolu !

                21 août 2018 à 12:09:15

                quenti77 a écrit:

                Pour éviter les mauvais conseils, he te conseil cette vidéo @Romuald44 : https://youtu.be/8O-IeLRgsCI

                Rsync c'est pas un outils pour du déploiement et en plus même si tu travail dans un dossier à part le faire sur le serveur directement c'est pas très propre.


                Salut, j'ai regardé la vidéo et je t'avoue que j'ai quasiment rien compris. lol

                Dans ton message précédent tu donnes des vidéos de grafikart qui proposent des solutions pour déploiement.

                Si tu regardes la vidéo que je donne qui est de Grafikart aussi, dès la première minute, il dit que rsync permet de déployer une application.

                • Partager sur Facebook
                • Partager sur Twitter
                  21 août 2018 à 12:29:33

                  Dans ces cas là c'est une erreur et rsync peut très bien servir pour sauvegarder le serveur mais pas pour mettre en ligne directement comme ça. Cela reste mieux que le faire à la main en FTP mais de nos jours on a GIT par exemple. @DevCode à très bien expliquer.
                  • Partager sur Facebook
                  • Partager sur Twitter
                    21 août 2018 à 13:50:04

                    Un moment donné, faut argumenter parce que là je suis pas convaincu ^^
                    • Partager sur Facebook
                    • Partager sur Twitter
                      21 août 2018 à 14:09:28

                      Techniquement, tu peux déployer avec rsync. Mais git a tellement plus d'avantage à être utiliser que rsync n'est pas forcément la meilleure solution à utiliser. Mais les avantages de git ne sont plus à démontrer. Quelqu'un avait poser la question sur stackexchange, si tu veux y jeter un coup d'oeil : https://security.stackexchange.com/questions/45452/is-using-git-for-deploying-a-bad-practice
                      • Partager sur Facebook
                      • Partager sur Twitter

                      Pensez à mettre vos sujets en résolu !

                        21 août 2018 à 14:13:34

                        +1 @DevCode. L'argumentation serait les avantages de git au complets et donc trop long à énumérer :D

                        Tu travail avec git @Romuald44 ?

                        • Partager sur Facebook
                        • Partager sur Twitter
                          21 août 2018 à 14:25:26

                          non je n'utilise pas git, c'est pour ça que je proposais rsync (je connais que ça) pour déployer et mettre a jour son projet, je trouve ça pratique et simple.

                          je devrais me mettre à git oui.

                          Merci pour le lien DevCode

                          • Partager sur Facebook
                          • Partager sur Twitter
                            21 août 2018 à 15:00:56

                            Attention cependant, j'ai essayé de mettre en place un déploiement continu avec GitLab sur mon serveur mutualisé OVH mais ... apparemment, il existerait une WhiteList OVH qui empêche Gitlab de se connecter à OVH (et vice-versa) en SSH.

                            Vous avez déjà entendu ce genre de chose?

                            • Partager sur Facebook
                            • Partager sur Twitter

                            Gérer mon projet PHP

                            × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                            × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                            • Editeur
                            • Markdown