Sas 02 et Mercurial
By Mihamina Rakotomandimby on Monday 2 January 2012, 17:43 - formation - Permalink
Avant d'aller plus loin dans le développement d'application, il est nécessaire de maîtriser l'outil utilisé en interne pour collaborer: Mercurial.
Système de gestion de code source
Mercurial est un système qui permet de faciliter la collaboration des développeurs sur un projet.
Il a plusieurs fonctionalités, et permet beaucoup de choses.
- Qu'avez-vous appris sur Mercurial?
- Comment se passe votre "premier contact" avec l'outil?
Comments
Aujourd'hui, nous avons débuté notre journée par les collectes des nouvelles sur l'Internet, puis nous avons fait des recherches sur l'utilisation d'un logiciel de gestion de code source et de gestion de version.
L'après midi, avant de passer à la pratique, nous avons fait un petit exposé sur le Mercurial, qui est un logiciel de gestion de version et aussi un logiciel qui permet aux développeur de travailler ensemble sur un même projet et surtout de suivre chaque action.
Pendant le premier contact avec l’outil, nous avons rencontré des difficultés à cloner le répertoire source, mais l'intervention du formateur nous a aidé beaucoup.
A part le clone, il y a encore beaucoup de chose à apprendre sur le Mercurial.
Aujourd'hui , la matinée est consacrée à la recherche de document sur Mercurial , après, on a fait un petit exposé à ce sujet histoire de savoir à quel point on le maitrise théoriquement .Ensuite , lorsque les zones d'ombres sont éclaircis , on nous a confié un projet de javascript en utilisant Mercurial comme système de gestion de version . Comme il s'agit de travailler en groupe , on a partager les taches entre nous . Lors de mon premier contact , je suis complétement déboussolé par rapport à l' environnement et surtout car c' est la première fois que j'utilise un système de gestion de version . D'ailleurs , je suis bloqué dès la configuration de TotoiseHg dans "Global Seatting" et surtout lors de la création du clone .
Depuis ce matin, on a fait une recherche sur Mercurial. J'ai retenu que Mercurial est un Système de Gestion de Version décentralisé (ou Distributed Concurrent Version System). Mercurial est outil indispensable pour le développement en équipe. Il permet de visualiser l'historique pour pouvoir revenir en arrière en cas de problème.
A propos de TortoiseHG, on est confronté à un petit problème: après le clonage du dépôt, le petit icône vert ne s'affiche pas même si on modifie le dépôt local. on utilise TortoiseHG 2.2.1. On croyait que peut être c'est à cause de la version que l'icône reste comme ça, ou non.
Mercural est un logiciel de gestion de version décentralisé. Il permet aux utilisateurs de travailler sans connecter au gestionnaire de version.
On a cloné le dépôt venant du serveur dev5. Après, on a crée un nouveau fichier inscription.html dans le répertoire de travail et on fait le commit de la modification et on a cliqué sur push pour publier la modification.
Comme le GIT et le svn, mercuri al est un outil de contrôle de version décentralisée .
Il permet notamment de travailler en parallèle avec d’autres personnes sur un même projet
Aujourd’hui on a fait cloner le projet javascript et faire une modification en créant un fichier html « inscription », puis on a envoyé cette modification au serveur central dev5 après avoir fait un commit
Ce matin, nous avons fait des recherches sur l'utilisation de logiciel de gestion de code source et de gestion de version comme Mercurial, puis les nouvelles comme d'habitude. A partir de ces recherches et l'exposé de cette après-midi, nous avons obtenu qu'il soit nécessaire d'utiliser Mercurial lors d'un travail d'équipe pour faciliter la méthode de travail. Ensuite, nous avons installé TortoiseHG pour faire la pratique, mais nous avons rencontré des difficultés sur la configuration comme l'erreur de clonage. Enfin ce problème a été résolu par des indications donnant du formateur en modifiant l'adresse IP du dev5. D'ou le premier contact avec l’outil n’est pas du tout facile, mais ceci nécessite des efforts pour le maitriser.
Quand on se renseigne sur le sujet, il est dit que: Mercurial est un logiciel de gestion décentralisé. Son utilité se fait surtout remarquer dans l'élaboration d'un grand projet (un projets qui regroupent 20 développeurs voir même plus par exemple). TortoiseHG, un outil basé sur mercurial permet de faire cette gestion de version. Une fois que l'outil est installé, il faut le configuré, et parmi les principaux paramètres à ne pas oublier figurent: L'identifiant de celui qui va effectué le commit, la source indiquant l'emplacement de l'hôte, l'emplacement du dépot local. Si ces paramètres ne sont pas précisé, alors, l'outil va générer une erreur.
Pendant la matinée, nous avons fait la pratique du Mercurial sur TortoiseHG comme la création d'une branche, un commit, l'utilisation du push/pull et update. Nous avons beaucoup de difficultés à les manipuler, nous devrons remettre toujours à zéro notre projet qui est complétement en désordre.
L'après-midi, nous avons fait la première formation sur le Mercurial, nous sommes encore dans le module niveau 1 mais nous avons déjà acquis la base du Mercurial.
Maintenant, nous savons comment et à quel moment nous devrons créer une branche, ajouter un commit, faire le push/pull, l'update, et le merge.
Nous savons aussi maintenant que avant de travailler sur Mercurial, il faut bien organiser les différents processus de travail pour qu'il n'y a pas des désordres ou des conflits.
L'utilisation de mercurial via tortoiseHG nous a fait comprendre l'utilité des systèmes de gestion de version. Son principe, diviser les tâches par branche pour que chaque développeur peut coder en quiétude dans son coin, développer en parallèle et synchroniser le travail.
Pour se faire, le développeur doit d'abord "cloner" le dépôt centrale dans son poste de travail (machine) et faire un "update" pour récupérer les fichiers et de les recopier dans son répértoire de travail. C'est dans le répertoire de travail que le développeur modifie les fichier du projet. Avant la modification, il doit d'abord créer une branche, puis faire un "commit" pour l'enregistrement au dépôt.Un "commit" et un "update" fait référence à l'échange entre l'espace de travail du développeur et le dépôt local. après avoir été convaincu des versions faites, le développeur doit faire un "push" pour mettre à jour le dépôt centrale afin que les autres développeur puissent récupérer et mettent à jour leurs dépôt local via un "pull". Les commande "push" et "pull" sont donc utilisées au relations dépôt-dépôt.
Concernant les branches, chaque développeur a sa propre branche. La dernière révision qui n'a pas d'enfant est le "head", mais celle qui a la date le plus récent est le "tip". Un "tip" est donc "un head" qui a la date le plus récent. Un "head" peut être un "tip" si on n'a qu'une seule branche.
Après avoir terminer les travaux, pour les développeur, on doit faire un "merge". Un "merge" c'est la fusion des travaux, plus précisément, des "head" et "tip" pour avoir la dernière révision que peut rendre à un client.
Après un "merge", on peut rencontrer un problème tel que les conflits de code, si les développeurs ont changé le même portion de code. Mercurial, lors du "merge" informe ce problème et donne une solution.
Pour éviter donc ce problème, il vaut mieux de ne pas déplacer les blocs de codes, il faut maintenir leurs position tel qu'ils sont mais on peut modifier leur contenu.
Chaque développeur d'un même projet qui utilise un logiciel de versions doivent cloner le dépot central.
Ensuite ils doivent faire un update de leur dépot local respectifs avant de travailler chacun de leur côté. Ceci dans le but de synchroniser le dépot local et l 'espace de travail.
Durant l'intervention, chacun sera amené à effectué des commits, des updates, des push et des pull.
Généralement on fait
- un "commit", quand on trouve que le travail est bien fait, fonctionne bien, et que l'on veut que le dépot local se mette à jour des modifications effectué sur l'espace de travail.
- un "Update", quand on veut que son espace de travail se mette à jour avec son dépot local ou si on veut annulé les modifications effectués dernièrement (cette technique marche uniquement que lorsque le commit n'a pas encore effectué de commit, dans ce cas l'espace de travail va se mettre à jour sur les derniers sauvegardes du dépot local).
- Un "push" lorsqu'on veut que le dépot central se mette à niveau des modifications de notre dépot local.
- Et inversement un "pull", lorsqu'on veut que le dépot local se mette à niveau par rapport au dépot central.
Lors d' un push, le depot central va remarquer les modifications de chacun, et de ce fait, il y a la création de branche. Aussi lorsqu'on fait un pull, il faut bien se repérer et se mettre sur le HEAD adéquat du poste qui ait été affilié au développeur.
Ce matin, on essai de travailler avec Mercurial sur TortoiseHG. Après avoir fini le clonage, on passe à la création de la branche à partir du Workbench pour pouvoir partager les tâches de travail, en utilisant le commit, l’update, le push et le pull. Cette partie nous a dépensée beaucoup de temps parce qu’apprendre Mercurial pour les débutants n’est pas facile.
La formation sur le cours Mercurial qui a été fait par le Formateur cette après-midi nous aide à faire comprendre l’importance d’utilisation du Mercurial dans le travail. Nous avons acquis la différence entre le dépôt et l’espace de travail, le «Tip » et le «head » dans une branche. L’utilisation d’Update est spécifié pour la communication d’un dépôt local vers un répertoire de travail, mais à part le commit est utilisé pour faire la mise à jour de la communication du répertoire de travail vers le dépôt local ou le dépôt central.
Aujourd'hui, nous avons tous consacrés notre temps dans le projet Javascript. Nous avons dû réunir avant tout pour bien partager les tâches, pour normaliser notre commit et surtout pour le structure d'espace de travail.
Pour le cas du Mercurial, nous avons déjà acquis quelque notion de base.
Aujourd'hui, la journée est consacrée à la continuation et l'amélioration des travaux sur javascript gérés sous Mercurial . De ce fait , le matin , on a fait un mise à jour de notre répertoire de travail par rapport au Merge effectuer hier ,c'est alors qu'on a continuer de travailler sur notre branche :"Recherche et Tri" . 3 Commit ont étés faits : d'une part , un Commit sur la réintégration HTML qui consiste généralement à remplacer des balises Table par des balises Div qui ne correspondent pas à la finalité de l'intégration . D'autre part , un autre commit pour la création d'un menu déroulant qui est une interface attractive de notre branche . Enfin , un commit , le dernier mais non des moindres qui désigne l'affichage dynamique des produits selon leur nombres . Ainsi fait , on a fait un Push pour envoyer notre travail au dépôt .
Ce matin, chaque binôme a fait un pull puis update pour avoir la dernière version qu'on a fusionné hier. Ensuite, nous avons continué à développer et à améliorer notre projet Javascript en modifiant la méthode de travail suivant les consignes du Formateur, à propos de la norme du codage, les commentaires,etc.
La fin de la journée, tous les binômes ont fait un "commit", puis un "push" pour envoyer leur travail durant la journée avant de les fusionner.
Ce matin, on a fais un "pull" pour avoir la dernière version d'hier, puis "update" pour mettre notre espace de travail.
Puis, on a commencer à travailler: on a réorganiser le travail. Les équipes ont eu du mal à traiter les balises "table" avec javascript, alors nous dans l'affichage, on a décider de réorganiser la page en utilisant des balises "div" afin de faciliter le travail dans le sas02. Et aussi, à cause de la désordre du page après la migration vers la feuille de style - certains attributs de la balise "table" n'ont pas d'équivalence en css-. Après avoir terminé une tâche et qu'on est satisfait du code, on a fait un "commit".
Cet après-midi, on a fait un "push" pour partager la nouvelle page aux autres développeur du sas02.
En mercurial, il existe une commande nommée merge, sa fonctionnalité est de fusionner le travail de chaque branche pour ne former qu'un bloc. Lors du prochain pull, On remarquera le merge dans la structure des branches. Au prochaine update, lorsqu'on visualise les branches on verra la les branches fusionnés, mais aussi, sur le côté la branche où l'on doit continuer son travail.
Aujourd'hui, on a fait la mise en pratique sur tortoiseHg en faisant les commandes "pull", "push", "update", "commit", "merge". Cette mise en pratique est combinée avec le développement du projet demandé ayant 3 branches distinctes ("inscription", "recherche","tri"). A la fin de la journée, on a fusionné (merge) notre travail.
Concernant la manipulation de mercurial d'aujourd'hui, faire un "merge" veut dire ne faire une fusion que entre 2 révisions. Et le merge doit se faire toujours sur la branche principale (dans notre exemple, c'est la branche livraison). Pour cela, on doit d'abord se placer sur le HEAD d'une branche (par exemple, branche tri) en faisant la commande "update", après on fait le merge avec la branche livraison et ainsi de suite pour les autres HEAD des autres branches. Et concernant la manipulation de Javascript, il faut gérer les erreurs en utilisant try et catch ainsi que d'utiliser la programmation orienteé objet pour avoir une meilleure compréhension des codes.
D'après les consignes du formateur à propos de la structure du code, la normalisation et les diverses corrections et optimisations, nous avons pu finaliser notre projet Javascript. Pendant la phase du projet, nous avons appris beaucoup de choses dans le monde professionnel comme l'esprit d'équipe, l'organisation et surtout la manipulation du logiciel TortoiseHG. Le parcours dans la SAS nous ouvre l'esprit professionnel, et surtout, il nous donne de jour en jour de l'expérience et il enrichi notre connaissance du développement web.
LE COTE TECHNIQUE DES MERGES:
Le secret dans le merge, c'est de se trouver dans la bonne branche. Supposons que l'on ait une branche rapport (qui permet au directeur de projet d'avoir un aperçu de l'état actuel du travail de son équipe) et une autre branche qui est design par exemple.
Si je me met à jour sur design, et que je merge avec rapport, cela signifie que je mets à jour la branche rapport ou j'informe mon supérieur de l'état actuel de mes travaux.
Inversement, si je me mets à jour sur rapport, et que je merge vers design, cela signifie que je met à jour mon dépot local, mais aussi que je m'informe sur l'avancement de mon équipe (cette dernière, est très utile surtout si les travaux sont dépendants).
Aujourd'hui, on a fait quelques corrections suivant les consignes du formateur à propos des normalisations et du formatage du code source.
On a appris à développer en équipe et à s'organiser. On se rend compte que même avec un système de gestion de version, qui est un outil pour travailler en équipe, rien ne va si on ne s'arrange et ne s'organise pas. Mercurial nous aide à organiser et à planifier le déroulement du projet.
Aujourd'hui, la journée a été consacrée à la continuation de notre projet javascript . Pour ma part , ma tache avec ma collègue Aina est de réaliser l'intégration depuis le début de la partie "Inscription" . L'un des plus grand défis est de concevoir les expressions régulières puisque notre branche s'occupe de la validation des formulaires(nom , prénom , nom d’utilisateur, mot de passe et e mail) dont une qui consiste à ce que le nom , le prénom ne contienne que des lettres ; Une autre pour le nom d'utilisateur et le mot de passe qui ne contiennent uniquement que des caractères alpha numériques . Ensuite vient la validation d' e mail , une tache très complexe puisque le RegEx correspondant doit correspondre à un motif bien défini . Enfin , l'un des moment forts de la journée est de créer une affichage d'un formulaire de validation qui ne s'affiche que lorsque toutes les données sont valides par rapport aux RegEx qui leur définis .
Les mots-clés du jour :
_Root,DNS,ICANN,Registrar,NIC,OVH
_Application native VS application Web Based
_Sencha,SVG
Aujourd'hui, le Formateur a corrigé notre travail à propos du Mercurial et du Javascript, telles les codes du développement et le fusion que nous avons fait la dernière fois. L'après-midi, nous avons recrée le travail sur la partie inscription suivant les consignes donnant du Formateur.
Ensuite, après avoir fini le développement et que toutes les formulaires ont été valide, nous avons décidé de créer une nouvelle branche nommée "inscription" pour mettre cette partie de travail, puis le fusionner avec la branche "livraison" après le "commit" et le "push".