Autopsie de notre processus de développement
Saviez-vous que tout ce que ça prend pour coder un site web ou une application (côté technique), c’est un simple éditeur de texte et un accès à un serveur, pour remplacer un à un les fichiers contenant des modifications ou des ajouts ? Chez Spektrum, le processus de développement est beaucoup plus élaboré. Dans son ensemble, plusieurs étapes interreliées permettent de faire passer le code source sur notre poste de travail jusqu’au navigateur de milliers de personnes en moins de 5 minutes. En tant que développeur, j’ai décidé de donner un petit break à notre aspirante geek pour vous proposer un survol de notre méthodologie.
Utilisons l’exemple d’une boutique en ligne qui veut ajouter une fonctionnalité permettant de recueillir les courriels de ses visiteurs pour leur envoyer des courriels promotionnels. Vous découvrirez ainsi à quoi peut bien ressembler une journée dans la vie d’un développeur chez Spektrum. Vous allez voir, c’est passsssssionnant.
1. Le développement
La magie commence sur notre poste de travail. J'ai devant moi cette fameuse boutique en ligne dans un environnement isolé de celle sur internet. Je peux, par exemple, décider d’effectuer une transaction sans qu’elle ne se retrouve dans l'entrepôt, ou ajouter des produits sans qu’ils ne s'affichent sur la version en ligne. C'est ce qu'on appelle l'environnement local, ou l'environnement de développement.
Pour recueillir les courriels des visiteurs, je vais écrire le code nécessaire afin de stocker cette information dans un endroit bien précis à l'intérieur de notre base de données. Ensuite, il faut préparer le visuel, composé d'une boite de texte et d’un bouton, qui sera intégré dans une nouvelle section sur la page d'accueil.
2. Les tests unitaires
Notre fonctionnalité est maintenant en place. Cependant, pour affirmer qu'elle est terminée, il faudra procéder à l'écriture des tests unitaires. Grosso modo, les tests unitaires sont une technique qui assure l’opération adéquate de notre fonctionnalité, telle qu’elle a été pensée. Ils permettent d'offrir un niveau de qualité supérieur au client. Ces tests unitaires peuvent être exécutés à n'importe quel moment lors du développement afin de détecter des erreurs de conception. Puisque ces tests sont automatisés, ils garantissent que ce qui fonctionne fonctionnera toujours car l'ensemble des tests sont exécutés lors de chaque modification de code.
Dans ce cas précis, je vais écrire un test unitaire qui confirme que mon courriel s'enregistre bien dans la base de données et un autre pour m'assurer que la boite de texte supporte l'ensemble de formats de courriels possibles. Si ces deux tests unitaires n'existaient pas, j'aurais à faire des validations moi-même, en allant cliquer sur les pages de l’application. Imaginez si les employés de Google avaient à cliquer partout et à essayer toutes les fonctionnalités de leur moteur de recherche lors de chaque déploiement de leur application! Ce serait impossible à gérer, en plus d’occasionner une immense perte de temps et d’argent.
3. Le versionnage
Maintenant que j'ai vérifié que mon système fonctionne correctement, je vais sauvegarder cette information dans notre répertoire de code source. Un système de contrôle de versions propose une gamme d'outils qui permet de stocker et de versionner les fichiers du projet ainsi que leur contenu. Ainsi, le système conserve toutes les versions successives. Il permet notamment d'enregistrer l'auteur et la date des modifications de manière unique tout en rendant la version en cours disponible à l'équipe entière.
D'un point de vue plus général, c'est comme si à chaque sauvegarde d'un fichier texte, nous y apposions une date et que nous le stockions sur une clef USB. Chacune des versions demeure donc accessible à n'importe quel moment, et à n'importe qui y ayant accès.
4. L’intégration continue
Lorsqu'une nouvelle version du logiciel est enregistrée, le processus d'intégration continue s’enclenche automatiquement. Cette étape ultime permet de construire l'ensemble des morceaux de notre application en un seul fichier après avoir vérifié que l'ensemble des tests unitaires sont valides. Dans un cas de succès, l'intégration continue s'occupe de déployer l'application vers la solution d'hébergement. Dans le cas où un ou plusieurs tests unitaires provoquent un échec, les développeurs de l'équipe reçoivent immédiatement une notification et le déploiement est annulé. Il faut comprendre que cette pratique se déroule sur une autre machine (dans ce fameux cloud) que notre poste de travail. Cela permet de s'assurer que l'application fonctionne ailleurs que sur notre poste de travail.
J'aime comparer l'intégration continue à la profession de serveur dans un restaurant. C'est la personne qui s'occupe d'assembler la commande, de vérifier sa conformité et son exactitude, puis de l'expédier au client.
5. C'est en ligne!
Le code est valide, les tests unitaires sont tous positifs et l'intégration continue est terminée. C'est à partir de maintenant que notre fonctionnalité se retrouve en ligne et devient disponible dans les navigateurs de l'ensemble des utilisateurs. C'est aussi à ce moment-là qu'on peut respirer un peu, jouer à NHL, bencher ou regarder les plantes pousser.
Ce processus va dans la même direction que l’approche agile. Il nous permet d'itérer très rapidement au gré des changements. Au final, on passe plus de temps à travailler les fonctionnalités de nos clients qu'à les déployer et les tester manuellement.
Vous avez aimé ce billet, mais êtes resté sur votre appétit? Rejoignez-nous sur le blogue 42 lignes, qui propose du contenu plus technique pour les développeurs et fanatiques de code!
Merci à Elias Djemil pour les photos.