Les mises en ligne sont toujours des moments délicats, que ce soit votre site perso, le site de votre client ou pour votre entreprise, une mise à jour importante voir critique… voilà donc quelques conseils accumulés par quelques années d’expérience.

1. Serveur de dev ISO-PROD
C’est peut être le premier conseil à mettre en place le plus vite possible, si vous développez sur une machine qui n’est pas conforme à celle qui est en ligne (même version d’applicatif web, de base de données, même configuration, etc…) vous pouvez vous attendre à quelques surprises, des comportements étranges, des librairies pas implémentées, des erreurs de gestion de fichiers, etc…
Tout particulièrement si vous êtes sous MAMP, un serveur de dev ne coûte pas cher, donc installez une version ISO-PROD, cela vous simplifiera beaucoup la vie.

2. Tester, tester, tester et re-tester (en dev)
On ne le dit jamais assez, mais avant de livrer une modification mineure (ou qui semble mineure) ou un site complet, testez le en local, sur une machine de dev, faites le tester par vos camarades, par les chefs de projets, etc… faites le tester par des inconnus (au projet) pour éviter les surprises. On ne teste jamais assez (on a jamais non plus vraiment le temps…) donc mettez vos petits camarades à contribution et mettez vous dans l’optique d’un utilisateur standard (évitez le Lorem machin truc, introduisez des vrai phrases avec des accents, des apostrophes, etc…).

3. Avoir une méthode infaillible (packaging)
Suivant la méthode de livraison (fichier par fichier, package ou SVN) vous devez trouver LA méthode qui vous permettra de ne jamais être pris en défaut. Notez tous les fichiers qui doivent être mis en ligne et recheckez pour ne pas en oublier. Etablissez une méthode simple et efficace que vous devez suivre tout le temps à la lettre, cela vous évitera de vous poser des questions sur la méthode de mise en ligne et vous pourrez ainsi vous concentrer sur d’autres aspects foirreux de votre mise en ligne.
Personnellement j’aime l’update SVN ou la méthode de pacquets. Vous faites tout simplement un tar avec la reproduction de l’arborescence des fichiers modifiers, vous transférerez détarrez et hop c’est fait.

4. Eviter les livraisons hasardeuses
Evitez les livraisons bancales de développements pas testés ou trop peu, les ajouts de modules par des entreprises tiers dont vous n’avez pas confiance, etc… au final c’est vous qui devrez redresser la situation, donc en cas de gros doute, bottez en touche.

5. Eviter les livraisons du vendredi à 18h37
C’est peut être un des conseils les plus avisés… ne JAMAIS, je dis bien jamais faire une mise en ligne précipitée un soir, sans l’appui de votre équipe (et tout particulièrement des développeurs qui ont écrit le code), je sais que le cas arrive (trop?) souvent, mais c’est la pire des configurations: vous êtes fatigué, vous avez envie de rentrer à la maison, vous bâclez votre mise en ligne, le serveur est en rade, vous tenter de réparer dans la précipitation et vous aggravez le cas… une horreur
Si ce n’est pas une mise à jour critique, refusez tout simplement la mise en ligne!

6. Une seule personne en charge
Une des (nombreuses) sources de problèmes peut venir de la multiplication des personnes en charge de la mise en ligne (et du partage des accès root - berk ça c’est vilain, mais bon). Au lieu de X personnes qui mettent en ligne leur bouts de code respectifs, choisissez une seule personne en charge de la mise en ligne et donc de récupérer tous les éléments à mettre en ligne. Au moins vous savez qui a mis en ligne quoi, à quel moment (et vous évitez la chasse aux sorcière pour l’envoi d’un fichier corrompu ou tronqué)

7. Penser à TOUT (et le noter)
Souvent dans la précipitation ou le stress on oublie des choses: modification une configuration, changer le modèle de données, remonter un bout de base de données, supprimer certains anciens fichiers inutiles, etc…
La SEULE méthode qui fonctionne correctement est de se faire une mini check-list et de s’y tenir.

8. Responsabiliser les développeurs
Même si vous mettez en ligne, les développeurs ont certaines responsabilités:
- tester ses développements et s’assurer qu’il ne reste aucun bug
- vous fournir une liste exhaustive des fichiers modifiés ou créés (et ça veut dire TOUS les fichiers)
- etc…
en cas de problèmes, vous devez leur remonter gentiment (mais fermement) les bretelles pour leur rappeler leurs devoirs.

9. Eviter les livraisons multiples à la chaîne
C’est aussi une source d’embrouille… vous avez mis une version en ligne qui a été semi testée, on vous envoi ensuite 27 demandes de mise en ligne partielles de bouts de code toutes les 9 minutes. Il y a u grand risque que vous fassiez ces livraisons à la barbare sans trop vous soucier des effets de bord (voir en écrabouillant par mégarde certains fichiers).
Temporisez et mettez en place des règles de test et de livraison unitaire (qui représente un développement finalisé et testé)

10. Savoir dire NON
Au final c’est vous qui serez dans la merde, donc si vous voyez un problème se profiler, n’hésitez pas à dire non, à refuser une livraison si elle vous paraît risquée. Proposez un autre planning incluant tests divers plus réaliste et plus conforme à vos règles de sécurité.

11. Bonus spécial: Sauvegardez!!!
On ne le dis jamais assez mais avant une livraison qui peut s’avérer foireuse, il est important de pouvoir rétablir la version antérieure du serveur en quelques minutes. Donc sauvegardez (code et base de données de préférence) et en cas de besoin vous pourrez faire un roll-back rapide et efficace.

Par expérience une mise en ligne est toujours une opération délicate, qui peut se solder par de vrais catastrophes… seule parade: une méthode infaillible pour ne rien (ou le moins possible) laisser au hasard.

Et vous des conseils, quelques anecdotes croustillantes ?

Depuis maintenant les quelques années que je travaille dans le développement pour le web, une fonctionnalité a changé ma vie de développeur: les outils de versionning et SubVersion en particulier (je parlerais de mes malheureuses aventures avec CVS peut être dans un autre post)

1. C’est quoi un outil de versionning
Un outil de versionning c’est un outil qui va vous permettre de stocker différentes version de vos fichiers. Il existe plusieurs types d’outils de versionning (si je me trompes pas Microsoft à lui aussi un outil de versionning), mais les plus connus sont CVS et son petit cousin SubVersion.

2. Pourquoi le mettre en place?
Si vous êtes plusieurs à travailler sur un projet en particulier si certains fichiers sont en commun, si vous désirez garder une trace des différentes versions de vos fichiers… les outils de versionning sont faits pour vous.
Pour résumer si vous travaillez dans le développement, vous avez 98% de chance d’avoir besoin de cet outil (même pour les graphistes cela peut se révéler très utile).

3. Les contraintes
Elles sont pu nombreuses:
- de la discipline (s’astreindre à suivre la procédure en place, ne pas buypasser le système même si cela paraît plus simple, au final tout le monde y perds)
- updater et commiter souvent (ce sont les deux actions principales pour mettre à jour et envoyer une nouvelle version du fichier)
- commenter ses commit (si vous avez 275 versions d’un fichier en une semaine, même si les révisions sont notées par heure d’envoi, sans commentaires efficaces vous allez vous y perdre très vite)

4. Architecture typique

Imaginons par exemple que vous ayez deux développeurs: machin et bidule, une plateforme de test et une plateforme de production.
L’architecture typique est d’avoir 4 environnements distincts tous synchronisés avec votre Repository (l’endroit où subversion stocke les fichiers et leurs modifications)

5. Les défauts?
Ils ne sont pas nombreux:
- expliquer et éduquer comment bien utiliser subversion (et avec certains ça peut prendre du temps)
- devoir résoudre certains conflits “à la main”

Et vous est ce que vous utilisez des outils de versionning?

Petite séance de debuggage CSS avec Dame Tartine, qui pour l’occasion essaye de caser le plus grand nombre d’ordinateurs sur une même table.
Le debuggage c’est toujours un peu la galère, même en essayant de faire le code le plus propre possible et le plus cross-plateforme possible, il y a toujours du travail.
Que ce soit pour le CSS ou le javascript… plusieurs OS, plusieurs Browsers: pleins de possibilité de plantages et de merdouilles. Même si il est possible d’émuler plus ou moins certains navigateurs sur certaines machines, le meilleur moyen reste encore d’avoir physiquement ces différents environnements à disposition.

Le debuggage est aussi une galère pour les chefs de projets… puisque difficilement quantifiable, on peut estimer “à la louche” quel temps devrait prendre tel ou tel correction de bug, mais aucune estimation fiable.

Et vous c’est quoi votre méthode de debuggage?

Suite et presque fin des résultats de l’enquête des salaires des Travailleurs Du Web, avec la (grosse) partie de cette enquête: les Développeurs, la catégorie la plus représentée avec 168 personnes sur 547 (un peu plus de 30% du panel)

Sexe

Voilà un phénomène intéressant et qui dément de façon partielle les constatations précédentes… un salaire moyen pour les femmes supérieur à celui des hommes et un salaire minimum lui aussi supérieur, par contre une grande différence entre le salaire maximal masculin et féminin (40% de plus, c’est énorme!).

Age

A part les personnes qui n’ont pas communiqué leur âge (et un rigolo qui apparemment a deux ans!) la courbe suit une courbe ascendante avec deux pics notables à 26 et 30 ans.

Expérience

La aussi une courbe globalement ascendante avec deux spécificité: un pic à partir de 4 ans d’expérience puis un plafond, avant de remonter à partir de 7 ans d’expérience.
Là aussi le phénomène pré-junior, post-sénior semble se confirmer, c’est à dire une évolution constante avec le titre “junior” puis une stagnation du salaire et enfin un redémarrage en tant que sénior.

Type d’entreprise

Première remarque: des écarts de salaires très prononcés sauf pour les agences de com et les annonceurs privés.
Ensuite le salaire moyen est relativement stable suivant les structures (autour de 30 k€) avec comme d’habitude l’exception des WebAgnecy, cancres de la classe avec un salaire moyen de 24 (et un prix minimum de 12… une erreur ou alors un stage, qui peut se faire payer 12?)
C’est une des surprises de cette étude, je pensais que les différences entre les types de structures serait plus flagrant.

Taille de l’entreprise

Une autre surprise de cette étude, il semble se confirmer que le salaire moyen dépende de la taille globale de l’entreprise… ceci dit les prix mini et max varient énormément avec des différences particulièrement criantes pour les micro-srtuctures (moins de 50 salariés). Le phénomène des salaires particulièrement élevés dans ces petites structures s’explique facilement par le “développeur star”

Type de contrat

Malgré une certaine harmonie (sauf pour le CDD et Autre) du salaire moyen, on peut noter quelques différences notables, comme le tassement du prix maximal pour le CDD…

Que peut-on en conclure?
Pas de réelle surprise à part la différence homme-femme qui reste très présente mais sous une autre forme et le fait que apparemment être dans une entreprise semble mieux payer (ce que je n’ai pas expérimenté, mais…)

Et vous vous en pensez quoi?

On recherche un Développeur Php/MySQL Freelance pour nous aider pendant 20 à 40 jours/homme (ou femme ah ah! je recopie texto la super blague pas misogyne du tout de mon patron).
- Très bonne maîtrise de PHP et MySQL
- Personne indépendante et débrouillarde, qui code proprement… (ça c’est vraiment important)
- Projet ultra intéressant, équipe sympa, environnement de travail agréable
- Mécanicien Picooz (un vrai plus)
- Sais éviter les missiles (en mousse mais quand même!)

Les personnes intéressées peuvent nous contacter à rh@trouverunvin.fr