jeudi 29 mars 2018

Git tuto rapide no bullshit

Vous cherchez un tuto complet et ultra-rapide pour réaliser la gestion des configurations de vos codes sources avec Git ? C'est ici.
Git Tuto rapide

Créer un nouveau dépôt Git

Pour créez un nouveau dossier, ouvrez le (placez vous dans le dossier à "giter") et exécutez la commande :

>git init

vous créez ainsi un nouveau dépôt.

Cloner un dépôt Git

Créez une copie de votre dépôt local en exécutant la commande :

>git clone /path/to/repository

Si vous utilisez un serveur distant, cette commande sera :

>git clone username@host:/path/to/repository

Les 3 Arbres

Votre dépôt local est composé de trois "arbres" gérés par git.
Le premier est votre espace de travail qui contient réellement vos fichiers.
Le second est un Index qui joue un rôle d'espace de transit pour vos fichiers et enfin HEAD
qui pointe vers la dernière validation que vous ayez faite.

Ajouter & valider

Vous pouvez proposer un changement (l'ajouter à l'Index) en exécutant les commandes :

>git add <filename>
>git add *


C'est la première étape dans un workflow git basique.
Pour valider ces changements, utilisez :

>git commit -m "Votre message de validation explicite"

Le fichier est donc ajouté au HEAD, mais pas encore dans votre dépôt distant.

Envoyer des changements

Vos changements sont maintenant dans le HEAD de la copie de votre dépôt local. Pour les envoyer à votre dépôt distant, exécutez la commande :

>git push origin master


Remplacez master par la branche dans laquelle vous souhaitez envoyer vos changements par exemple developement.

Si vous n'avez pas cloné votre dépôt existant et voulez le connecter à votre dépôt sur un serveur distant, vous devez l'ajouter avec :

>git remote add origin <server>

Maintenant, vous pouvez envoyer vos changements vers le serveur distant sélectionné

Branches

Les branches sont utilisées pour développer des fonctionnalités isolées des autres. La branche master est la branche par défaut quand vous créez un dépôt. Utilisez les autres branches pour le développement et fusionnez ensuite à la branche principale quand vous avez fini.

Créer une nouvelle branche nommée "feature_x" et changer la branche pour passer dessus utilisez :

>git checkout -b feature_x

Retourner sur la branche principale :

>git checkout master

et supprimer alors la branche secondaire :

>git branch -d feature_x

Une branche n'est pas disponible pour les autres tant que vous ne l'aurez pas envoyée vers votre dépôt distant :

>git push origin <branch>

Mettre à jour & fusionner

Pour savoir sur quelle branche vous êtes et dans quel état elle est :

>git status

Pour mettre à jour votre dépôt local vers les dernières validations, exécutez la commande :

>git pull

Pour vous positionner sur la branche master :

>git checkout master

Dans votre espace de travail pour récupérer et fusionner les changements distants.
Pour fusionner une autre branche avec la branche active (par exemple master), utilisez :

>git merge <branch>

Dans les deux cas, git tente d'auto-fusionner les changements. Malheureusement, ça n'est pas toujours possible et il en résulte des conflits. Vous devez alors régler ces conflits manuellement en éditant les fichiers indiqués par git. Après l'avoir fait, vous devez les marquer comme fusionnés avec la commande :

>git add <filename>

Après avoir fusionné les changements, vous pouvez en avoir un aperçu en utilisant :

>git diff <source_branch> <target_branch>

Tags

Il est nettement recommandé de créer des tags pour les releases de programmes. C'est un concept connu, qui existe aussi dans SVN et c'est tout simple. Vous pouvez créer un tag nommé 1.0.0 en exécutant la commande :

>git tag 1.0.0 1b3a1d62ff

Le 1b3a1d62ff désigne les 10 premiers caractères de l'identifiant du changement que vous voulez référencer avec ce tag. Vous pouvez obtenir cet identifiant avec :

>git log

Vous pouvez utiliser moins de caractères pour cet identifiant, il doit juste rester unique.

Remplacer les changements locaux

Dans le cas où, vous auriez fait quelque chose de travers (ce qui bien entendu n'arrive jamais ;) Vous pouvez annuler les changements locaux en utilisant cette commande :

>git checkout --<filename>

Cela remplacera les changements dans votre arbre de travail avec le dernier contenu du HEAD. Les changements déjà ajoutés à l'index, aussi bien les nouveaux fichiers, seront gardés.

Si à la place, vous voulez supprimer tous les changements et les validations locales, récupérer le dernier historique depuis le serveur et pointer la branche principale locale dessus, procédez comme ceci :

>git fetch origin
>git reset --hard origin/master

Voilà, ce tuto est déjà terminé !

Merci à la page du site Ici mais je me serais bien passer de la mise en page disons trop ... heu comment dire ... ball shit justement ! 

Have fun!

Références :
https://blog.imirhil.fr/2013/04/14/git-gestion-de-conf-aujourdhui.html
Plus qu'un article sur les Gestionnaires de conf CSV, SVN et les autres une vraie bonne critique de ce qui se fait en matière de gestion de configuration.

http://nvie.com/posts/a-successful-git-branching-model/
Gestion des branches un diagramme de toute beauté

http://rogerdudler.github.io/git-guide/index.fr.html
Cette page est vraiment pas ... cool mais bon c'est bien fait


Outils Redmine de gestion de projet - Workflow et Tracker ou Intéractions

Vous pouvez avoir travaillé avec Redmine sans connaitre la totalité du Workflow car on ne vous a jamais expliqué les différents rôles et les différentes actions possibles en fonction du rôle que l'on vous a attribué. Ceci n'est pas exhaustif malheureusement pour avoir la totalité des rôles et des workflows associés il faut être le "grand master central".

Mais voici quand même mes notes dans deux rôles principaux : le Client gestionnaire et le Responsable projet pour un type d’interaction : L'Anomalie

Workflow Redmine pour le Client gestionnaire

Gestion d'une Anomalie pour le Client gestionnaire

Workflow Redmine pour le Responsable Projet

Gestion d'une Anomalie pour le Responsable projet

J'appelle cela une interaction car il s'agit bien d'échange de quantité de travail entre les différents intervenants dans Redmine le terme utilisé en anglais est Tracker.

Voilà donc également les différents types d'interactions (ou Trackers) :

  • Exigence
  • Evolution
  • Anomalie
  • Assitance
  • Organisation
  • Tâche

Avec ça on a une bonne vision globale du "Workflow" dans Redmine. J'aurais aimé un graphique un schéma plutôt qu'un tableau mais je pense qu'il est difficile à réaliser entièrement vous pourrez vous même le faire pour explicité (rendre plus compréhensible) certaines partie du Workflow de Redmine.

Les modules de Redmine

L'onglet Configuration de Redmine permet de d'installer ou non différents modules :

Configuration de Redmine - Les modules

Redmine est un outil très complet, collaboratif qui permet de travailler en toute sérénité avec une équipe de développement élargie.

  • Suivi des demandes
  • Suivi du temps passé
  • Publication d'annonces 
  • Publication de fichiers
  • Wiki
  • Dépôt de sources 
  • Forums de discussion
  • Clandrier
  • Gantt
  • Agile
  • Revues de code

Voilà, on à vu très rapidement les éléments qui permettent de gérer le Workflow des tickets au sein de Redmine.

mercredi 14 mars 2018

C'est quoi le Release Management

C'est quoi ou What is, le Release Management ? Ok c'est une étape vers l'acquisition de la culture DevOps mais encore ? C'est qu'elle étape au sein du processus Agile.

                        DEV                               |                                 OPS
Define Sprint Deliver Product Backlog | Monitor Release Pipeline Curtomers Operate

Le release management c'est automatiser l'étape entre le delivery Dev et le Release Pipeline Ops.

PowerShell/CLI

Scripts permettant d'automatiser toutes les étapes
Security
Active directory
Team foundation Server Groups

Database Changes

SSDT

Have rollback strategy

Triggering Releases

Command Line
REST API

Bon alors évidemment là c'est pour vendre du Azure mais le principe serait le même sur d'autres infras si tant est que l'on puisse mettre en place les outils équivalents.

Azure

Azure Power Shell
IaaS
PaaS
SaaS



Key Features
Configuration as Code

samedi 3 mars 2018

TortoiseGit et Tuto Git ce que manquait pour bien démarrer

Vous ne vous en sortez pas avec uniquement Git en ligne de commande et même avec Git UI c'est pas encore ça. En installant TortoiseGit on espère bien que tout va s'arranger. Voilà ce qu'il manquait.

TortoiseGit

Création d'un repo Git en local sur mon Disque Dur

Grâce à Git, je peux créer un "repo Git" où je veux, il me suffit de cliquer droit sur n'importe quel répertoire :


Bon ya encore une popup de daub(bip) à cliquer ...


Pffff c'est lourd c'est trucs linuxiens à la con(bip)
Ce qui est cool avec git c'est qu'en supprimant le répertoire ".git" on est déconnecté du gestionnaire de codes sources. On peut faire un peu la même chose avec TFS mais c'est légèrement plus compliqué, il faut aller dans le fichier .csproj supprimer des lignes c'est délicat.

Et voilà ce qu'il me maquait la liaison avec Github, jusque là on pouvait penser que c'était de la magie.

Création d'un repositorie distant dans mon Github

Dans mon Github, j'ai créer également un nouveau repositorie :



Liaison le Repositorie Git Local et le Repositorie Git Distant

Je retourne sur le repositorie locale et je fais Bouton droit -> TortoiseGit -> Settings


Bouton droit->TortoiseGit->Settings
Dans TortoiseGit Settings -> Git -> Remote



On progresse, on progresse



Il suffit d'entrer l'URL du repositorie Github distant, en cliquant sur OK un boite de dial :


Allons y Fetchons ... encore un boite de dial ...



Encore un petit OK ca devrait arriver ...



Voilà : git.exe fetch -v --porgress "RFID-CloverWiever" : Succcess

Cette fois on dirait bien cela y est !

Regardons les logs par curiosité :



Cette fois on y est ...

Voilà donc comment lié un repositorie locale et un repositorie distant dans Github grâce à TortoiseGit.

Have fun!

vendredi 2 mars 2018

Git avec TortoiseGit et GitLab - Comment merger deux branches ?

Effectuer un merge entre deux branches avec les outils TortoiseGit et GitLab autour de Git. Les concepts Git sont un peu différents, le checkout c'est pour se retrouver sur une branche. Le checkin c'est un commit. On peut faire un Puch ou un Fecth. Et pour m'y retrouver, j'ai avec moi TortoiseGit et Gitlab avec lesquels je vais varier les commandes et les plaisirs.

Je prends des notes rapides, ce n'est pas un tuto par la main mais plutôt pour compléter mes précédents posts sur le même sujet.

Un fois l'install de TortoiseGit effectuée :

https://tortoisegit.org/

Voici toutes les commandes Windows de TortoiseGit :



C'est énorme ! Toutes ces commandes ...

Git Commit -> "master" ... je suis donc dans la branche "master"

Je cherche à afficher les branches pour merger la branche "development" dans la branche "master" c'est :

TortoiseGit -> Browse References



Affiche toutes les branches :

Oui c'est pas très fun comme interface
Alors après je me suis amusé, en ligne de commande :

>git checkout master
>git checkout development

Puis TortoiseGit Browser les deux sont bien synchros :



Et dans Gitlab :



Je pourrais cliquer sur le bouton "Merge request" dans Gitlab mais les commandes sont tellement simples.

Merger ma banche developpement dans la branch master

Je me lance donc en ligne de commande. Pour merger la branche development sur la branch master, il me suffit de faire :

>git checkout master
>git merge development

Et je n'oublie pas un petit :

>git push


Pour pousser les nouvelles modifications de la branch master sur le gitLab.

Je merge la branche développement dans la branche master - Vue départ
Voici ce que j'obtiens à l'arrivée :

Vue finale les deux branches sont mergées

L'étiquette du haut que l'on en voit pas bien c'est "development master".

That's All Folks !

Au passage, je me fais des zip de "master" et de "development" pour pallier à une éventuelle catastrophe :



Mais il n'y aura aucune catastrophe ça fonctionne impec !

Have great fun !