Je suis d'accord que modifier les fichiers en live, c'est loin d'être fiable.
Après, rien n'oblige à faire lourd si t'en n'as pas les ressources, xanthius: tu peux très bien modifier tes fichiers en local, en montant ta stack sur ton poste (ce qui est très facile avec une stack Apache/PHP/MySQL via *amp: tu télécharges puis installe le .exe, et roule), tu dev sur ton poste, tu fais tes tests (avec ton navigateur ouvert sur http://localhost ce qui est bien plus fiable et à jour qu'un "aperçu live", que ton coda2 propose), puis tu balances le tout par FTP une fois fini (soit à la mano, soit en auto). Je ne sais pas si ton outil le propose, mais FileZilla (qui est gratuit
) permet de n'uploader que les fichiers modifiés. Si t'as accès au SSH du serveur, c'est encore mieux, puisque tu pourras faire du rsync comme dit par Sephi
C'est pas forcément l'idéal, un outil de deploy automatisé fera probablement mieux, mais c'est tout simple à mettre en place (un poil plus compliqué que l'édition live, mais le très léger surcout de complexité peut être vite compensé, le jour où tes modifs live planteront tout...!).
Pour ma part, je dev ainsi: j'ai mon projet en local, versionné sous Mercurial. Je fais mes modifications là-dessus, et je test sur le navigateur en même temps, à l'adresse http://isometry.localhost par exemple [une simple entrée dans le fichier host la faisant pointer vers 127.0.0.1 et un fichier de conf Apache gère ce VirtualHost). Je peux donc dev en offline sans soucis. Une fois la feature acceptable, je commit dans Mercurial, puis je lance mon script de deploy. Ce dernier fais quelques checks manos, puis crée une tarball gz du projet [en ignorant certains fichiers et en déplaçant d'autres fichiers] qu'il upload sur le serveur, dans le dossier du projet ["/reinom/isometry/"]. Le script extrait ensuite la tarball, exécute les commandes SQL qu'elle contient, puis fais pointer le lien symbolique "/reinom/isometry/current/" vers le dossier où la tarball a été extraite. Cette tarball contient les dossiers internes [type "php/" "sql/"] et "externes" ["www/"] du projet sur lequel pointe le nom de domaine (http://isometry.reinom.com pointe sur /reinom/isometry/current/www)
C'est à peu près ce que Magallanes fait, mais cela me permet d'aller hooker des traitements à différents endroits (un script mettant les tickets Mantis à jour après la release, un script lançant SonarQube, des checks sur les fichiers avant de les déployer, la construction automatique du SQL de mise à jour, etc). C'est un peu lourd à mettre en place, mais ayant des brouettes de projets, c'est devenu rentable pour moi.
PS: ah, et éditer en live signifie "laisser tomber le débogguer". C'est pourtant souvent pratique
Après, rien n'oblige à faire lourd si t'en n'as pas les ressources, xanthius: tu peux très bien modifier tes fichiers en local, en montant ta stack sur ton poste (ce qui est très facile avec une stack Apache/PHP/MySQL via *amp: tu télécharges puis installe le .exe, et roule), tu dev sur ton poste, tu fais tes tests (avec ton navigateur ouvert sur http://localhost ce qui est bien plus fiable et à jour qu'un "aperçu live", que ton coda2 propose), puis tu balances le tout par FTP une fois fini (soit à la mano, soit en auto). Je ne sais pas si ton outil le propose, mais FileZilla (qui est gratuit
) permet de n'uploader que les fichiers modifiés. Si t'as accès au SSH du serveur, c'est encore mieux, puisque tu pourras faire du rsync comme dit par SephiC'est pas forcément l'idéal, un outil de deploy automatisé fera probablement mieux, mais c'est tout simple à mettre en place (un poil plus compliqué que l'édition live, mais le très léger surcout de complexité peut être vite compensé, le jour où tes modifs live planteront tout...!).
Pour ma part, je dev ainsi: j'ai mon projet en local, versionné sous Mercurial. Je fais mes modifications là-dessus, et je test sur le navigateur en même temps, à l'adresse http://isometry.localhost par exemple [une simple entrée dans le fichier host la faisant pointer vers 127.0.0.1 et un fichier de conf Apache gère ce VirtualHost). Je peux donc dev en offline sans soucis. Une fois la feature acceptable, je commit dans Mercurial, puis je lance mon script de deploy. Ce dernier fais quelques checks manos, puis crée une tarball gz du projet [en ignorant certains fichiers et en déplaçant d'autres fichiers] qu'il upload sur le serveur, dans le dossier du projet ["/reinom/isometry/"]. Le script extrait ensuite la tarball, exécute les commandes SQL qu'elle contient, puis fais pointer le lien symbolique "/reinom/isometry/current/" vers le dossier où la tarball a été extraite. Cette tarball contient les dossiers internes [type "php/" "sql/"] et "externes" ["www/"] du projet sur lequel pointe le nom de domaine (http://isometry.reinom.com pointe sur /reinom/isometry/current/www)
C'est à peu près ce que Magallanes fait, mais cela me permet d'aller hooker des traitements à différents endroits (un script mettant les tickets Mantis à jour après la release, un script lançant SonarQube, des checks sur les fichiers avant de les déployer, la construction automatique du SQL de mise à jour, etc). C'est un peu lourd à mettre en place, mais ayant des brouettes de projets, c'est devenu rentable pour moi.
PS: ah, et éditer en live signifie "laisser tomber le débogguer". C'est pourtant souvent pratique