lundi 30 novembre 2015

Un site web ASP.NET MVC 5 de A à Z - Initiation au versionning avec Git (partie 1)

Lors du précédent article, nous avions initié notre projet ASP.NET MVC 5. Au passage nous avions également choisi comme controleur de code source GIT. Dans le cas de cette série d'articles j'utiliserai la plateforme Github pour versionner mon code source.

Pourquoi un contrôleur de code source dès le début du projet ?

Le contrôleur de code source est essentiel pour gérer notre projet web quelque soit sa taille. Tout d'abord, un projet ne se fige très rarement : il y a toujours un moment ou on fait le évoluer : par exemple, on décide de rajouter une nouvelle page web, changer le style, faire des évolutions plus approfondies comme par exemple rajouter/modifier/supprimer une partie du code métier (une nouvelle règle imposée par notre client). Un projet informatique (web dans notre cas) vie : il faut qu'à tout moment on sache on est et d'où on vient. Notre contrôleur de code source va donc archiver pour nous notre code et surtout garder une trace de toutes les actions que l'on effectue dessus.
Mieux encore, imaginons qu'un nouveau développeur arrive sur le projet : on va potentiellement travailler sur le même bout de code : comment savoir donc ce qu'il aurait effectué comme changement lors de mon absence ? Imaginons qu'après avoir livrer en Production (environnement final utilisé par les utilisateurs cibles), on se rend compte qu'il y a un bug grave sur une page ou une régression (une fonctionnalité qui marchait jusque là) : que fait-on ? on devrait donc pouvoir revenir une version plus récente (RollBack).
Vous l'aurez compris, il vaut avoir dès le départ de notre projet au minimum un contrôleur de code source afin de tracer toutes les actions effectuer sur notre code.

Quel contrôleur de code source pour votre projet ?

Il existe une multitude de contrôleur de code source : Git, Source Safe, TFS, SVN, ...
TFS (Team Foundation Server) fait office de contrôleur de code source mais peut également utiliser Git comme contrôleur, car TFS est une plateforme plus large proposant d'autres services tels que la gestion de build continue, gestion de projet via des tableaux de bord (Scrum, Kanban), etc.
Si vous travaillez sous les technos Microsoft et que vous disposez des licences TFS, c'est la solution par excellence. Vous pourrez choisir Git comme contrôleur de code source (même avec TFS).
Git est de plus en plus répandu du fait de sa puissante : il est simple d'utilisation (de prime abord), et rapide, il dispose d'un gestionnaire de code via ligne de commande et est disponible sur toutes les plateforme (Windows, Linux, Mac). Git est également gratuit : ce qui en fait un avantage non négligeable.


Git dans notre projet
Lorsque l'on regarde dans notre répertoire de solution on retrouve un dossier caché '.git' qui nous indique la prise en en charge par le controleur de code source.


lorsqu'on ouvre la solution dans Visual Studio, nous pouvons accéder à notre gestionnaire de code source via l'onglet "Team Explorer", et cliquer sur la "prise électrique verte" pour se "plugger" à une git par exemple.




Dans mon cas présent, je vais me connecter à "Github". Il vous faudra au préalable vous créer un compte gratuitement sur Github.com.





On constate ici sous le volet 'Référentiels Git locaux' que notre solution est mapper en local (nous y reviendrons plus tard), en double cliquant sur notre solution mappé, une nouvelle fenetre s'affiche nous permettant de "pousser" notre code vers le serveur Git.



Cependant, n'ayant pas encore créer de "Repository distant" (en gros, c'est la référence de notre arborescence sur le serveur Git), il va nous falloir le créer : on peut le faire depuis le site de Github directement :


Une fois le "Repository" crée, on peut récupérer son Url et la saisir sous Visual Studio afin d'effectuer le mapping.


Une la connexion établie avec le serveur Git, nous allons pousser notre code sur le serveur. Pour cela, nous retournons dans notre explorateur de solution, puis nous "validons" dans un premier temps la connexion de notre solution. Une nouvelle fenêtre nous demandera d'effectuer un "push" (valider la première fois) et/où "sync" : le sync récupère également les éventuelles modifications effectuer sur le serveur par un autre utilisateur par exemple, ou depuis un autre Pc.


une fois que vous lancer la synchronisation, votre code sera publier sur votre "Repository distant". Votre première action est donc historisée et apparaît dans votre éditeur.


Dans cette première partie, nous avons juste vu comment se connecter à un "Repo distant". Cependant, nous n'avons pas encore définit de stratégie de "branching" : en Effet, comment fait-on si on travailler à plusieurs et sur des évolutions différentes ? Comment fait-on un "hotfix" en Prod ?
Nous verrons cela dans mon prochain article.

PS : Une petite vidéo intéressante sur Git :
https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Getting-Started-with-Git
Un lien intéressant su Git :
http://pcottle.github.io/learnGitBranching/

Aucun commentaire:

Enregistrer un commentaire