Création d'applications pour Mac OS X
Publié le jeudi 21 août 2008, aucun commentaire
Parmi les outils que je trouve essentiels en informatique, j'en connais au moins deux qui sont peu ou mal enseignés. Il s'agit du test et du contrôle de versions. Pour l'heure, je garde le test de côté et je vous parlerai ici du contrôle de versions. Ce premier article évoque les bénéfices qu'on peut attendre d'un outil de contrôle de version. Le prochain article détaillera les étapes à suivre pour activer un tel outil dans Xcode.
Vous est-il déjà arrivé d'avoir écrit un morceau de code dont vous êtes très fier, mais qui vous laisse l'impression qu'il pourrait être amélioré ? Qu'avez-vous fait ensuite ? Vous avez peut-être poursuivi sur la lancée, modifié une ligne ici, ajouté une fonction là, revu un peu l'architecture en prévision d'autres modifications dont vous venez d'avoir l'idée... Et puis patatras, plus rien ne marche ! Bien sûr, loi de Murphy oblige, vous n'aviez pas sauvegardé votre travail initial. Il ne vous reste plus qu'à revenir en arrière petit à petit ou bien tout recommencer depuis le début.
Si vous êtes plus prudent, vous aurez sans doute sauvé votre travail régulièrement. Peut-être les premières fois en écrasant les anciennes modifications par les nouvelles, jusqu'au jour où vous vous apercevez que votre modification en cours ne marche pas, ni celle que vous avez sauvée. La version correcte était juste un peu plus ancienne... Peut-être décidez-vous alors de faire des sauvegardes successives dans des dossiers dont le nom inclut la date ou un quelconque repère unique, de façon à conserver toutes vos modifications. Dans ce dernier cas, vous n'êtes plus très loin du contrôle de versions et cet article vous intéressera certainement.
Un outil de contrôle de version fait exactement cela : conserver et retrouver l'historique des modifications du code source d'un logiciel. Il le fait de façon un peu plus élaborée qu'une collection de dossiers datés. D'abord, les versions successives ne sont pas sauvées in extenso : seules les modifications depuis la version précédente sont archivées. Cela permet de garder l'historique en utilisant une quantité de mémoire très faible.
Ensuite, l'historique n'est pas nécessairement linéraire. Il est possible de faire plusieurs évolutions parallèles à partir d'une même version antérieure. L'historique devient un arbre avec son tronc et ses branches, c'est un vocabulaire couramment utilisé parmi les outils de contrôle de versions. Quel est l'intérêt de cette pratique ?
Supposons que je sois l'auteur d'un super logiciel que j'ai baptisé fort à propos MonSuperLogiciel. La première version a déjà beaucoup de succès et j'ai commencé à développer des nouvelles fonctionnalités pour la deuxième version qui sera encore plus géniale. Et voici qu'un utilisateur découvre une erreur dans la première version. Le système de branches de l'outil de contrôle de versions me permet de corriger l'erreur de la version 1.0 et de rapidement proposer une version 1.1. Pendant ce temps je peux continuer à travailler sur la version 2.0, elle aussi issue de la version 1.0.
Enfin, un outil de contrôle de versions offre la possibilité inverse, à savoir réunir les modifications développées dans deux branches parallèles. L'analogie botanique trouve ici ses limites et le mot consacré est issu de l'anglais : l'opération est généralement appelée merge. Pour poursuivre sur mon exemple, l'intérêt du merge est que je peux intégrer la correction de l'erreur réalisée dans la version 1.1 de MonSuperLogiciel dans la branche consacrée au développement de la version 2.0.
Si vous souhaitez vous plonger un peu plus dans les arcanes du contrôle de versions, je vous invite à lire (en anglais) le dossier Source Control HOW TO sur le blog d'Eric Sink.
De nombreux outils de contrôle de version existent. Une liste incomplète existe sur Wikipédia. Certains sont plus en vogue ces temps-ci, comme par exemple Git ou Mercurial, pour lequel un petit guide pour Mac en français existe sur le blog Cocoa.fr. Mais si vous travaillez avec Xcode votre choix est réduit à trois : CVS, Subversion et Perforce.
Dans mon prochain article vous saurez pourquoi j'ai choisi Subversion et je vous expliquerai comment l'activer pour vos projets Xcode.
Soyez le premier à commenter cet article.
Les commentaires sont destinés à répondre en public à l'article visé et à ses commentaires déjà publiés. C'est pourquoi seul un pseudonyme vous est demandé ici. Si vous souhaitez échanger avec moi en privé, merci de me laisser un message via le menu contact en haut de la page.