Cet article s’appuie fortement sur l’article posté par Miso Engeneering. Pourquoi ? Tout simplement car nous avons les mêmes problématiques au sein de notre société ! C’est pourquoi j’ai décidé de reprendre l’article en l’adaptant à notre propre expérience… Comme vous pourrez le constater en comparant les deux articles, nos expériences se croisent !

Cela fait un long moment que j’essaye des outils de suivi de tâches de toutes formes et de toutes tailles. D’ailleurs, à OpenXtrem, là où je suis en poste actuellement, nous avons choisis d’utiliser Remember The Milk (RTM), en intégrant son API au sein même de notre framework. Ainsi nous pouvons gérer nos tâches directement depuis cet outil.
Cependant, puisque nous sommes une petite équipe, nous finissons tous par une utilisation conjointe d’un simple fichier texte où l’on a « vraiment » le suivi de nos tâches. Rien ne vaut un simple fichier texte pour le suivi des tâches détaillées personnelles et le suivi de projet. Personnellement je ne suis pas trop adepte de cette solution, et c’est bien pour ça que j’ai poussé un outil tel que RTM à mes collègues 😉 Une autre question qui survient généralement est comment inclure des extraits de code, des guides d’installation, des référentiels essentiels à l’équipe, etc… Pour cela nous utilisons un wiki, mais également Google Docs…
Enfin, troisième besoin commun, est un dépôt de logiciels, images, etc… Nous utilisons actuellement Dropbox avec un répertoire partagé !
Au final, on se retrouve à gérer nos tâches dans RTM (voir dans un fichier texte), le Wiki pour la documentation, les documents sur Google Docs et enfin Dropbox pour des fichiers ! Simple non ? 🙂

C’est pourquoi j’essaie de faire une veille active sur le sujet et éviter d’utiliser divers outils ! Récemment, tout comme Miso Engeneering, je me suis posée la question sur la possibilité d’utiliser simplement un dépôt Git sur nos propres serveurs, afin qu’il serve à toutes nos fins. Notamment, il nous faut un endroit pour faire le suivi de nos tâches personnelles et professionnelles, de stocker des exemples de code utiles partagés, de téléverser aléatoirement des fichiers, des notes, etc… En gros tout ce que l’équipe de développement a besoin d’accéder ! Malheureusement, il y a quelques obstacles à cette approche basée purement sur Git.

La première est qu’avec des fichiers et des documents partagés, vous ne voulez pas avoir à vous soucier constamment comment les envoyer et les récupérer, autrement dit se soucier de la synchronisation. Des changements interviennent tout le temps, le texte est modifié ou des fichiers sont ajoutés, et avoir à spécifier manuellement chaque changement de ligne dans un fichier texte n’a pas vraiment de sens pour ce cas d’utilisation. Nous voulons vraiment quelque chose comme Dropbox… Ainsi, dès qu’un fichier est modifié, les mises à jour sont automatiquement envoyées et récupérées.
Deuxièmement, je pense que nous avons vraiment besoin d’un outil pour afficher les fichiers au sein même du navigateur. Imaginez que nous voulions écrire un mémo en HTML, sans avoir son rendu réel… Il est donc nécessaire d’avoir un moyen pour ce référentiel partagé d’être consultable dans le navigateur.

Après avoir examiné différentes solutions, et afin de construire une « solution idéale », je suis donc tombé sur l’article de Miso Engeneering. Celle-ci m’a vraiment séduite (je vous expliquerais les raisons de celle-ci dans la suite de l’article)… Cette solution, fait appel à Gitdocs. Il s’agit d’un outil permettant de collaborer sur des documents et des fichiers sans effort en utilisant simplement Git et le système de fichiers. Il faut imaginer Gitdocs comme une combinaison de Google Docs et Dropbox, mais libre et Open-Source !

C’est après la lecture de cet article, que je me suis laissé séduire par la solution. Celle-ci semble vraiment simple et efficace à mettre en œuvre. D’ailleurs, Miso Engeneering explique parfaitement comme le faire. Je vais en reprendre les différentes étapes d’installation et d’utilisation.
Seule contrainte pour le moment, et pas la moindre, Gitdocs n’est supporté que par Mac OSX utilisant fsevent (je vous recommande de lire l’article du lien précédent sur Wikipedia afin d’en savoir davantage sur fsevent). Concernant les utilisateurs de Linux et Windows, l’équipe de Gitdocs annonce que le soutien pour ces deux systèmes d’exploitation est à venir très prochainement.

Installation

Une fois que vous avez réussi à vous procurez un Mac, et compris comment utiliser fsevent, la première étape va être naturellement d’installer Gitdocs.

Note : Pour cela, vous devez avoir ruby et rubygems.

Ensuite, il vous suffit de lancer la commande gem afin d’installer Gitdocs.

Si vous avez installé Growl, vous aurez probablement envie que celui-ci soit actif pour Gitdocs. Pour cela, il vous suffit de taper la commande suivante :

Une fois ces lignes lancées, vous êtes prêt à utiliser Gitdocs.

Utilisation

Gitdocs est une bibliothèque plutôt simple avec seulement quelques commandes de base. Vous devriez être en mesure d’ajouter des répertoires à surveiller pour Gitdocs, démarrer / arrêter Gitdocs et être en mesure de vérifier l’état de ce dernier.

Nous allons ajouter les dossiers à surveiller :

Note : Sachez que vous pouvez également demander à Gitdocs d’aller chercher un dépôt distant et le garder synchronisé avec : gitdocs create reperoire/local [email protected]:utilisateur/repertoire/distant/repo.git. Cette commande va permettre de cloner le répertoire distant et commencer à surveiller le chemin local.

Vous pouvez supprimer et enlever des chemins tout simplement :

Ensuite, il vous reste à démarrer Gitdocs :

Vous pouvez également arrêter et redémarrer Gitdocs si nécessaire.

En exécutant gitdocs status vous aurez une liste de l’état actuel de Gitdocs.

Une fois Gitdocs démarré, il vous suffit de commencer à éditer ou ajouter des fichiers à votre dépôt Git désigné. Les changements seront automatiquement synchronisés à votre répertoire local.

Enfin, pour explorer les répertoires synchronisés au sein de votre navigateur, il suffit de vous rendre à l’URL http://localhost:8888 afin d’accéder à tous vos répertoires dans le navigateur.

Conclusion

Pour le moment j’ai seulement testé en local Gitdocs ! Je pense (j’en suis sûr) que mes collaborateurs vont bien lire cet article et on en rediscutera à mon retour… Et oui, c’est direction LeWeb pour moi 😉

En tout cas, cela peut s’avérer un moyen très simple de gérer nos documents, fichiers, tâches, etc… Reste à voir comment le système réagit avec de multiples utilisateurs.

Gitdocs est un projet jeune, avec une roadmap très prometteuse, notamment avec un support pour les plateformes Linux et Windows, iOS et Android qui sont très attendues.

Qu’en pensez-vous ? L’avez-vous testé ? Des retours positifs ou négatifs ? Venez réagir…