Quelque chose m'attriste quand je vois la méthodologie employée par certains pour travailler sur du code shell ou PL/SQL. On ne vous a pas appris : c'est normal de faire des conneries !
- Pour le code shell, ils éditent directement sur le serveur de développement et ne récupèrent leurs sources que quand leur code fonctionne.
- Pour le PL/SQL, ils modifient le code directement en base de données et copient/collent ou enregistre le code en local lorsqu'il fonctionne.
Je n'ai qu'une chose à dire :
== You're doing it wrong! ==
Au boulot, nous travaillons (classiquement) avec Subversion. Svn, comme tous les gestionnaires de code source modernent utilise une sandbox qui est l'endroit ou vous modifiez localement le code source avant de la valider dans le dépôt central. Les jeunes et moins jeunes : vos modifications doivent d'abord être faites dans votre sandbox et toujours prètes à être commitées.
Avec la méthode évoquée plus haut, vous vous exposez simplement à perdre tout votre travail.
- Pour le shell, vous pouvez accidentellement écraser votre copie de travail sur le serveur avec votre copie locale en faisant une bête erreur de FTP.
- Un collègue peut involontairement supprimer vos modifications en faisant une installation(ce collègue peut se prénomer Hudson ou Jenkins, il y en a peut-être un dans votre équipe)
- Le point précédent est valable pour le PL/SQL.
- Pour le PL/SQL, comme pour le shell, en cas de crash ou d'indisponibilité du serveur, vous pouvez au mieux être dans l'incapacité de récupérer votre code, au pire vous le perdez. Vous êtes dans l'incapacité de livrer : c'est comme si vous n'aviez pas travaillé.
En synthèse, votre poste de développement est plus stable que le serveur. Vous en avez le contrôle total. Développez sur votre poste et testez sur le serveur. Vous pouvez également prendre le temps (10 minutes) d'automatiser le transfert et vos tests.
Remarques complémentaires
Dans des situations plus particulières, le code que vous travaillez peut être également modifié par un tier simultanément (c'est fou le monde moderne... OK, ça arrive souvent.). Travailler dans votre sandbox vous permet d'intégrer les modifications au fil de l'eau plutôt qu'en fin de dev (si vous travaillez avec un refactoreur psycopathe comme moi ça peut vite être le drame).
Vous pouvez compléter l'utilisation de Svn par un gestionnaire de code source décentralisé (comme Git ou Mercurial) que vous faites fonctionner en local. Git vous permet de faire des commit intermédiaires (c'est sur votre PC alors OSEF), de tester des choses dans des branches locales sans risquer de perdre ou de casser quoi que ce soit. À l'inverse, le dépôt central Svn ne devrait contenir que du code valide (mais ça ne vous empèche pas de commiter votre code baclé avant votre départ en congés).
