Quel logiciel de gestion de versions utilisez-vous ?
- CVS
- Git
- Mercurial
- Subversion / SVN
- Autre (précisez en commentaire)
0 votant
Au boulot, git en local et je push vers le repo svn du projet via git-svn. J’ai donc coché autre ;)
Au boulot comme à la maison , git only.
Git pour les projets à distance et/ou open source que nous publions sur Github.
Git est bien intégré dans Netbeans, ça aide!
Sinon je garde SVN pour les projets qui n’ont pas cette dimension distribuée.
1 « J'aime »
J’utilise Darcs, je travaille seul.
2 « J'aime »
Git, associé à git labs, que cela soit professionnel ou pour les projets persos.
Git sans hésiter, que ce soit pour des projets personnels, étudiants ou professionnels, le tout sur un gitlab.
1 « J'aime »
Hors sujet (mais pas tant que cela peut être :) ) : Gitlab c’est bien mais il y a pas mal de trucs a installé si on veut pas se prendre la tête songer à la virtualisation il y a des stacks ici. https://bitnami.com/stacks
J’utilise GitLab et GitLab CI, un clone de TravisCI conçu par la même équipe. C’est sûr il faut aimer bidouiller, mais il y a une excellent image docker, très régulièrement mise à jour.
J’adore Gitlab par contre on avait test Gitlab CI mais du coup je vois pas trop en quoi c’est un clone de TravisCI. Ou sinon il a bien évolué depuis… (> 6 mois qu’on s’en sert plus).
Je trouve que son concept se rapproche plus d’un CI standard à la Jenkins (qu’on utilise donc faisait doublon avec Gitlab CI) où tu écris tes jobs directement au niveau du CI contrairement à TravisCI où tu utilises un fichier .travis.yml à la racine de ton projet.
Il n’y a toujours pas d’équivalent au .travis.yml malheureusement. Il faut écrire des jobs sous forme de script shell qui s’executent sur des Runners (VM ou Container Docker). Ceci dit, le projet avance vite, et aujourd’hui je le trouve suffisant dans un contexte interne et bien plus simple et léger qu’un Jenkins.
En fait, le problème c’est qu’implémenter l’équivalent de .travis.yml nécessite d’avoir des runners pré-paramétrés pour ça. Sinon, la base est là, mais il manque encore des choses dans le coeur de GitLab CI pour pouvoir le faire (comme le fait de lire la configuration d’un job à partir d’un fichier du repository, même si c’est un simple script dans l’immédiat, pour l’instant ce n’est pas possible du tout).
C’est intéressant de lire le README github de travisCI qui explique la décomposition des différents projets. GitLab CI pourrait bien s’inspirer du projet Travis Build qui est capable de convertir le .travis.yml en script Shell. C’est à mon avis le plus gros du boulot, et il est déjà la en opensource sous license MIT :)
Ensuite il ne reste plus qu’a avoir des VM pré-paramétrées comme il faut pour chaque type de script, et roulez :)