Le workflow d’un développeur expliqué à nos clients

Réaliser une application, c’est concevoir et développer un produit. Le processus de conception est assez bien compris par les clients de One more thing Studio. En revanche, lorsqu’on parle développement, les sourcils ondulent…

Je remarque que dans un projet, très peu de temps est accordé pour expliquer la phase de développement (c’est bien connu, les développeurs travaillent dans l’ombre !). Dans cet article, je vais donc tenter de mettre les développeurs à l’honneur, en vous expliquant le workflow d’un développeur (comment est organisé son espace de travail) d’un point de vue théorique.

Les développeurs écrivent des lignes de code (jusque là, ça va), et ces lignes renvoient à différents services techniques. C’est cet ensemble qui rend possible la création d’une application. Pour cela, ce code doit être juste, c’est à dire générer ce qu’on veut qu’il génère. Et pour qu’il soit juste, il faut le tester.

Un développeur ne peut pas tester des nouvelles choses (ajouter des lignes de code) alors que des utilisateurs interagissent avec la même version du produit : les modifications du développeur auraient un impact direct sur l’application utilisée, et l’utilisateur ne comprendrait pas. Pour éviter ça, les développeurs utilisent différents espaces, appelés environnements. Au total, le développeur travaille sur trois environnements qui ont des objectifs bien distincts, chacun est dédié à une fonction spécifique.

DEVELOPPEMENT

L’environnement développement, c’est l’espace de travail du développeur. Il est rapidement mis à jour et contient la version la plus récente de l’application. C’est un peu le carnet de brouillon d’un journaliste : il peut rayer des choses, ajouter des nouvelles idées sans que ça ait un impact sur l’article final qui sera publié. Pareillement, le développeur peut faire des modifications dans son code sans changer directement l’interface de l’application. C’est l’espace dédié à la réflexion du développeur. Lorsqu’un bout de code est stable (et que le développeur est content de lui), il est mis sur l’environnement staging afin d’être testé.

STAGING

L’environnement staging permet de tester le code, et donc de voir si ça fonctionne bien dans l’application. Cet espace apparaît comme un sas entre l’espace de travail du développeur, et celui qui contient le code final qui sera publié. S’il y des bugs, ils sont évidemment remontés pour être revus dans l’environnement de développement. Si tout fonctionne comme prévu, le code est transféré dans l’environnement production. En fait, le code de l’environnement staging est toujours candidat à la publication, mais pas forcément retenu.

Pour reprendre l’analogie précédente, cet espace peut être représenté par la relecture du directeur de la maison d’édition : il peut pointer des mauvaises formulations dans l’article du journaliste, ce qui l’amènera à re travailler sur son carnet de brouillon. Cependant, si tout va bien, le directeur valide le contenu, avant qu’il soit envoyé en publication.

Je dirai que cet environnement est le plus important à comprendre pour le client puisque celui-ci doit être actif dans le processus de tests. Lorsqu’il lui est proposé de tester une application sur Testflight par exemple (service d’Apple), c’est l’environnement staging qui lui est présenté. Le client a donc la possibilité d’expérimenter son application et de remonter des éventuelles problèmes avant le passage en production. Quand on demande au client de faire des tests, il peut jouer avec son produit (presque finalisé), il lui est possible d’ajouter ou de supprimer des choses dans l’application, sans conséquences. En d’autres termes, s’il fait n’importe quoi, les utilisateurs finaux ne le verront pas. C’est l’avantage de cet environnement.

PRODUCTION

L’environnement production, quant à lui, contient la version définitive du code qui est dédié aux « vrais » utilisateurs. L’application finale que l’on publie sur le Store est branchée sur cet environnement. Retour à notre comparaison : on peut dire que cet espace qui contient le code final est le contenu éditorial d’un journal (tous les articles validés par la direction) que les gens pourront lire le dimanche matin, alors que l’Apple Store serait plutôt le kiosque(c’est à dire le moyen de publier le contenu).

Take home message : Prenez soin de toujours tester sur l’environnement staging !