Sommaire
Salut Nal,
Mon premier billet ici, après quelques années passées à lire ceux des autres, est pour vous parler des derniers outils que j'ai eu l'occasion de tester.
Je cherchais les outils nécessaires pour développer collaborativement un programme open source, ou fermé dans le cadre d'une petite entreprise. Plus généralement je cherche un workflow efficace qui s'adapte aux diverses situations que je rencontre.
Besoins
Les fonctionnalités recherchées sont :
- Le versionnage du code source, bien évidemment, mais aussi un moyen de visualisation.
- La possibilité de travailler collaborativement, et concurremment. La gestion des branches est donc nécessaire. La possibilité de soumettre des patches et pour le relecteur de les commenter, diminue de beaucoup la difficulté de participation à un projet libre.
- Fournir simplement et élégamment de la documentation.
- Gérer, trier, archiver les bogues.
- Si l'outil est libre c'est encore mieux.
- Si je peux l'installer où bon me semble, afin d'avoir le contrôle sur mes données, c'est un plus non négligeable. Notamment pour des projets en PME.
- Pour un développement orienté tests, j'ai besoin d'un outil d'intégration continue. Pour faire simple, les jeux de tests doivent être lancés à chaque commit, et j'ai besoin d'être notifié du résultat. La validité des tests augmente avec le nombre d'environnements différents sur lesquels ils sont lancés (Linux, Android, MacOS, Windows etc., mais aussi avec différentes options de compilation).
- Une interface graphique digne de ce millénaire, à savoir sobre et simpliste. Pas de milliers d'options de configurations, pas de couleurs criardes, pas de publicité, etc.
Mes données chez les autres
Une première approche pourrait être « Je ne me prends pas la tête et j'utilise des services dans le cloud ».
Github
Il est presque inutile de présenter le mastodonte qu'est Github. Parmi les quelques de forges que j'ai eu l'occasion de tester (Github, CodingTeam, Savannah, Sourceforge, Redmine, Launchpad un petit peu), Github est de loin la meilleure. (Mais je veux bien qu'on me parle de bitbucket et consorts). Github est plus qu'une forge, presque un réseau social de développeurs. J'ai déjà vu des offres d'emploi demandant un compte Github actif.
Github a toutes les fonctionnalités majeures dont j'ai besoin :
- Gestion des bugs simple et efficace (possibilité de trier par tag et par release)
- Un wiki pour la documentation, la gestion du format markdown pour voir les README via l'interface web est un plus.
- La « killer feature » de Github, c'est selon moi la gestion des « pull request ». Ou pour ceux qui ne connaissent pas, la gestion interactive des patches. Pour faire court, on forke un projet en deux clics. Dès lors on a un dépôt git sur lequel on peut apporter les modifications que l'on veut. Enfin on peut soumettre les contributions au dépôt original. Les développeurs du projet upstream peuvent facilement reviewer, commenter, tester les modifications, puis valider ou non la demande.
- En bonus, des snippets de code et des statistiques sur les dépôts
- Enfin la sobriété de l'interface de Github correspond tout à fait à mes attentes.
Travis CI
Toute une panoplie de services peuvent se brancher sur Github en deux clics, parmi eux Travis CI. Travis est un service d'intégration continue, gratuit pour le projets publics de Github, payant pour les autres.
L'idée est simple, à chaque commit sur un projet Github, Travis exécute une batterie de tests et notifie l'auteur du résultat (par mail, irc etc.). Là où Travis est fort c'est qu'à chaque fois, une nouvelle machine virtuelle est déployée, garantissant un environnement de test neutre. Et comme c'est une machine virtuelle, on a les droits administrateur et le script de test peut installer toutes les dépendances dont le programme a besoin.
Travis permet notamment de lancer des builds en parallèle, même pour les comptes gratuits. Enfin pour les applications web, il est toujours possible d'effectuer une batterie de tests en utilisant xvfb, qui permet d'émuler un environnement X. Les builds sont tués après 10000 lignes de logs, 10 minutes sans log ou simplement si le build dépasse 50 minutes.
Parmi les faiblesses de travis il y a le peu d'images disponibles. En gros on a le choix entre une Ubuntu 12.04 LTS et une image de MacOS pour les projets ObjectiveC. Par contre on peut indiquer à Travis sur quel langages vont porter les tests afin qu'il déploie une image avec des paquets préinstallés. Petit moins, les logs des builds scintillent avec Firefox, sur toutes mes machines.
Coveralls
Enfin pour donner un peu de récursivité à tout ces services, il est possible de brancher des outils à Travis. L'un deux est coveralls, qui permet de visualiser et de faire quelques statistiques sur les données de couvertures de code extraites par gcov, durant les tests lancés par Travis. Coveralls supporte plusieurs langages dont Ruby on Rails, Python, PHP, Node.js, C/C++, Scala
Mes données chez moi
Mais tout ça c'était avant ça :
Gitlab CE
Je suis étonné de voir à quel point Gitlab est méconnu par rapport à sa puissance. Gitlab a toutes les fonctionnalités de Github (voir plus haut), l'interface est presque à la limite du plagiat. La différence qui fait toute la différence est énorme :
Gitlab CE est sous license MIT, et installable partout où vous le voulez. Pas besoin de payer pour un dépôt privé, et vos données sont chez vous. Pour les dépôts publics et pour ceux qui ne veulent pas déployer un serveur, il est toujours possible d'utiliser gitlab.com
Il existe aussi une version payante de Gitlab avec quelques fonctionnalités en plus (sur les annuaires LDAP etc.)
Gitlab CI
Mais comme si ça ne suffisait pas, les éditeurs de Gitlab ont aussi développé leur outil d'intégration continue Gitlab CI. Gitlab CI se branche en deux clics à Gitlab et possède une interface vraiment sobre et efficace.
Par rapport à Travis, il possède quelques fonctionnalités en plus, dont les statistiques sur les builds, et quelques fonctionnalités en moins, dont les notifications par IRC (bien que ça devrait être possible à scripter assez facilement).
La différence principale est que les builds ne sont pas exécutés dans des machines virtuelles, mais par des « runners ». Un runner est un client qui va lancer la batterie de test voulue. Ils peuvent être multiples et surtout, peuvent être n'importe quelle machine. Pas forcément le serveur sur lequel Gitlab CI est installé, mais votre PC ou le mien par exemple. On peut lancer des runners sous Linux, Windows, et à mon avis ça ne devrait pas être trop compliqué sous Mac. Les résultats sont en suite transmis au serveur.
Les runners semblent être considérés indifféremment de leur plateforme, je n'ai pas trouvé de moyen de s'assurer que les tests sont exécutés deux fois, sur deux distributions différentes par exemple.
Le principal inconvénient est qu'on risque d'avoir des comportements différents, d'une part si la compilation et les tests ont des effets de bord, et d'autre part en fonction des environnements sur lesquels ils sont exécutés. Mais c'est là qu'intervient Docker.
Docker
Pour reprendre Wikipedia, Docker d'automatisation de déploiement d'applications dans des conteneurs logiciels sous license Apache 2.0. Pour démystifier cette formulation barbare, Docker est un programme qui déploie des images de système d'exploitation dans des conteneurs plutôt que dans des machines virtuelles, exécute des programmes sur ces images. Le mécanisme est le même que celui de la machine virtuelle, mais moins coûteux en ressources. Certainement moins sécurisé, mais dans notre cas de figure c'est sans doute suffisant.
Une image issue de leur site qui illustre la différence.
Bien que Docker soit un projet n'ayant même pas un an, il était en Novembre le 14ème projet le plus populaire de Github.
Docker permet de déployer des images d'un large pannel de systèmes d'exploitation (ubuntu, debian, fedora, archlinux etc.). Il est possible aussi de créer ses propres images, avec par exemple des dépendances pré-installées. Ce qui peut manquer c'est par contre des images de systèmes propriétaires (Windows, MacOS).
La bonne nouvelle c'est que ça semble se brancher facilement sur Gitlab CI.
Et maintenant
Maintenant il est temps que je teste Gitlab & co. sur la durée pour voir ce qu'il en est. Je n'ai pas encore eu l'occasion de tester tout ce dont j'ai parlé pour le moment, vous voudrez bien m'excuser les possibles approximations. Pour le moment, j'ai trouvé l'installation assez simple et les fonctionnalités sont aux rendez-vous. Je ferais sans doute un retour d'expérience dans quelques mois.
Enjoie
# Gitlab : très bien
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
J'ai installé il y a quelques semaines Gitlab : c'est parfait pour ceux qui aiment bien Github, ils seront en terre connue. L'installation, bien qu'un peu longue puisqu'il faut tout faire à la main, se passe toutefois sans problème si on est sur debian/ubuntu. La doc est trés détaillée et finalement très simple : il suffit juste de taper les lignes de commandes indiquées, et ça roule.
À la recherche moi aussi d'un outil d'intégration continue, j'ai finalement abandonné gitlab-ci. Trop simpliste pour moi, même si ça peut convenir à d'autres. Les principaux reproches :
Bref, déçu par gitlab-ci, qui a pourtant un bel atout : il s'interface très bien avec gitlab. On lui indique où est le gitlab, on lui donne les droits, et il sait lister les projets associés à ton login, et permet de créer un build associé à un projet en un clic (mais faut rajouter le temps de l'écriture du script…).
Du coup, je me suis retourné vers jenkins :-/
Au passage, j'ai vu strider-cd, ça ressemble à du gitlab-ci mais en modulaire. Cependant, le manque pour l'instant de plugins ne le rend pas forcément plus interessant (notamment pas de plugin pour le moment pour avoir le même style de runner que Gitlab-ci, mais il y en a un qui s’appuie sur Docker…).
[^] # Re: Gitlab : très bien
Posté par azmeuk (site web personnel) . Évalué à 2.
À noter, dans feuille de route, on apprend que Gitlab CI compte :
C'est assez prometteur !
# GitLab tres bien aussi
Posté par ben (site web personnel) . Évalué à 2.
J'ai installé GitLab fin 2011 et la moindre des choses qu'on puisse dire, c'est que c'est un projet très dynamique. Le seul problème pour moi c'est la mise à jours mensuelle qui peut vite lasser, surtout que parfois ça casse (je me rappelle le passage a MySQL). Bon, je crois que c'est mieux maintenant, mais c'est toujours une nouvelle version chaque mois et ça serait chouette qu'il propose une version stable…
# Gitlab s'autoheberge
Posté par plietar . Évalué à 1.
En lisant ce journal, je me rends compte que Gitlab s'autoheberge depuis peu, un must pour toute forge.
Sinon Gitlab ça a l'air sympa, mais mon raspberry pi n'a jamais réussi a tenir la charge.
Pour l’intégration avec docker, ils ne fournissent qu'un Dockerfile (fichier qui décrit comment construire une image). Gitlab est-il capable de lancer un nouveau conteneur à chaque build, où doit-on les lancer avant, au quel cas ils sont réutilisés, et donc on perd l’environnement propre.
Le mieux est à mon avis d'écrire un ficher Dockerfile pour le projet, et de créer une image à chaque build et de lancer les tests dedans. Pas besoin d’intégration particulière avec le système de CI.
# Pour un premier journal...
Posté par liberforce (site web personnel) . Évalué à 3.
Tu t'en sors très bien ;). Merci pour cet article instructif.
[^] # Re: Pour un premier journal...
Posté par Albert_ . Évalué à 4.
Un moderateur pourrait meme le promouvoir en depeche non?
[^] # Re: Pour un premier journal...
Posté par liberforce (site web personnel) . Évalué à 3.
P'têt bin. Faudrait juste corriger les mots manquants à "Docker d'automatisation de déploiement d'applications"
# Échange de commit inter instances
Posté par kaliko (site web personnel) . Évalué à 2.
J'avoue ne pas avoir beaucoup cherché (j'héberge moi-même mes dépôts de source), mais que ce soit sur gitorious ou github, je n'ai jamais vu la possibilité de faire des "pull-request"® entre dépôts sur des serveurs différents.
Par exemple, pourquoi ne pourrais-je demander à un projet sur gitorious.org de tirer des modifications que j'ai publiées sur mon dépôt git://git.kaliko.me/projet.git ?
Il me semble que c'est une des fonctionnalités fondamentale de git àmha (le D de DVCS). Je comprends l'absence de cette fonctionnalité chez github dont l’intérêt est
plutôt d'agréger autour de sa plate-forme le plus de projets (via les "fork"®), qu'en est il de gitlab sur cet aspect social ? Différente instances de gitlab peuvent elles communiquer entre elles ? avec d'autres dépôt git ?
[^] # Re: Échange de commit inter instances
Posté par plietar . Évalué à 3.
Entre simple dépôts git, ou avec des services différents, l'interaction serait compliquée voir impossible au delà du simple "fork". Pas de Pull/Merge Request, pas de lien automatique vers les issues, … Autant faire un "git pull", "git remote add" et "git push" en console.
Pour gitlab par contre, ce serait intéressant. Il y a eu une demande, mais je ne trouve pas les merge requests mentionnées.
[^] # Re: Échange de commit inter instances
Posté par azmeuk (site web personnel) . Évalué à -1.
Si je ne me trompe pas, les pull request ne sont pas une fonctionnalité de git, mais des forges. C'est peut-être pour cela que github a eu du succès, ils faisaient parti des pionniers du pull request. Techniquement ça peut se comprendre, les pull request étant des commits en attente, pouvoir envoyer des pull request à un dépôt git lambda reviendrait à pouvoir faire exploser son espace disque.
[^] # Re: Échange de commit inter instances
Posté par feth . Évalué à 3.
git implémentait seulement les "request pull" en effet… ça consiste à envoyer un mail avec une url git et à décrire ce qu'on y trouvera de nouveau.
En fait c'est mieux, non ?
[^] # Re: Échange de commit inter instances
Posté par kaliko (site web personnel) . Évalué à 1.
Pour préciser suite au commentaire de plietar et azmeuk:
Je parle bien-sur d'échanges de commit entre différentes "forge", applications web au dessus de git.
Git gérant déjà cela à la "unix" via le formatage d'un patch à piper dans un mail :)
[^] # Re: Échange de commit inter instances
Posté par ®om (site web personnel) . Évalué à 6.
Git intègre nativement un mécanisme de pull request :
D'ailleurs, Linus n'aime pas la fonctionnalité similaire de GitHub.
blog.rom1v.com
# Atlassian
Posté par Spack . Évalué à 2.
OK, ce n'est pas libre et c'est même en Java mais je dois avouer que les produits Atlassian sont assez efficaces pour la gestion de projet. Le groupe Confluence, Jira et Stash permet de construire un environnement de gestion de projet très agréable à utiliser.
# Docker
Posté par Spack . Évalué à 3.
Malheureusement, ça ne pourra pas marcher car Docker est différent de la virtualisation qui elle émule le matériel.
Docker se base sur LXC qui lui même utilise les les Namespaces et cgroups du noyau Linux. Il s'agit de séparer les processus en différents groupes mais en utilisant toujours le même noyau. En clair, seule une autre distribution Linux peut être exécutée.
# Merci pour l'info
Posté par flan (site web personnel) . Évalué à 3.
Je ne connaissais pas du tout gitlab, et ça paraît plutôt pas mal.
Je sais que dans quelque temps je vais refaire ma forge perso (actuellement basée sur du svn + redmine, avec du github pour des projets publics), et gitlab me paraît un bon candidat. C'est simplement dommage à mes yeux que ça soit en Ruby, va falloir que j'apprenne à faire avec… (ce n'est pas une critique de Ruby, c'est qu'autant je maîtrise le déploiement des sites en Python, autant je ne connais rien en Ruby)
[^] # Re: Merci pour l'info
Posté par Seb (site web personnel) . Évalué à 3.
Il existe RhodeCode pour ceux qui préfère installer du Python, et ça supporte aussi bien Mercurial que Git.
[^] # Re: Merci pour l'info
Posté par bat13 . Évalué à 1.
Je rebondis justement sur ta réponse pour poser une autre question : je cherche moi aussi une forge assez complète, mais j'aimerais en trouver une qui gère principalement des dépôts mercurial, mais aussi, si possible du git et svn.
Et le tout pas trop gourmand pour pouvoir tourner sur un serveur atom (uniquement quelques utilisateurs)
Une idée ?
[^] # Re: Merci pour l'info
Posté par Seb (site web personnel) . Évalué à 1.
Ça dépend ce que tu entends par "assez complète", RhodeCode ne fait que gestion de dépôts (qu'on peut organiser en groupe/sous-groupe), les droits d'accès aux groupes/dépôts, un pastebin/gist intégré, gestion des pull-requests, intégration avec LDAP…
Mais il n'y a pas de wiki, et pas de bugtracker intégré (la communication avec d'autres bugtrackers est encouragée).
Il n'y a pas non plus de prise en charge SVN. On peut seulement activer
hgsubversiondans le panneau d'administration pour cloner un dépôt SVN dans un dépôt Mercurial.Niveau ressources, ça tourne plutôt bien sur de l'Atom, ma première installation était sur un Fit-PC (Atom Z530), que j'ai migré sur un Kimsufi chez OVH (Atom N2800), et mon instance occupe actuellement 150mo en mémoire. Ceci-dit c'est une forge perso, il n'y a jamais plus de 2 utilisateurs, mais ça doit passer sans problème avec une petite équipe.
À voir sinon du côté de Trac ?
[^] # Re: Merci pour l'info
Posté par bat13 . Évalué à 1.
Dans ce cas, je pencherais plutôt du côté de RedMine/ChiliProject (il est encore vivant ce fork ?), car j'utilisais RedMine auparavant et le trouvais pas mal, et je crois savoir qu'on peut y ajouter la gestion de plusieurs types de dépôts.
Et Trac (du moins quand j'avais regardé) ne savait pas gérer - simplement - plusieurs projets
[^] # Re: Merci pour l'info
Posté par flan (site web personnel) . Évalué à 1.
Ça m'a l'air un peu loin de Gitlab, malheureusement :( Enfin, je regarderai quand même le moment venu, merci :)
# Penser à regarder gitorious
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Dans la même veine que gitlab il y a aussi gitorious.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.