GitlabHQ – de SQLite à mySQL

Comme notre installation de GitlabHQ à SRMvision est faite pour rester, nous avons décidé de migrer de la base SQLite vers un système plus simple à gérer pour nous : mySQL.
Les étapes sont assez simple, premièrement, configurons mySQL :

create database gitlab; 
grant all privileges on gitlab.* to "gitlab" identified by "gitlab"; 
flush privileges;

Ensuite récupérons les données existantes dans GitlabHQ, arrêtez votre serveur, puis, depuis le dossier de GitlabHQ :

bundle exec rake db:data:dump RAILS_ENV=production

ceci va créer un fichier db/data.yml. Tout ce qu’il vous reste à faire maintenant est de reconfigurer GitlabHQ pour lui dire de se connecter à mySQL et d’y intégrer les données existantes.
La configuration de la base de données à utiliser se trouve dans le fichier config/database.yml, sauvegardez le et récupérez le database.yml.example comme base de travail:

mv config/database.yml config/database.yml.old
cp config/database.yml.example config/database.yml

Il ne vous reste qu’à éditer le fichier pour refléter votre configuration, seule la partie production du fichier est utile dans notre cas :

development:
  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: gitlabhq_development
  pool: 5
  username: root
  password: "secure password"
  # socket: /tmp/mysql.sock

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: gitlabhq_test
  pool: 5
  username: root
  password: "secure password"
  # socket: /tmp/mysql.sock

production:
  adapter: mysql2
  encoding: utf8
  reconnect: true # permet de se reconnecter quand le service mysql redémarre
  database: gitlab # à remplacer avec le nom de votre base
  pool: 5
  username: gitlab # à remplacer avec vos identifiants
  password: "gitlab" # à remplacer avec vos identifiants
  socket: /var/run/mysqld/mysqld.sock # mysql socket location on debian

Une fois ceci fait, il vous reste à créer le schéma et à importer vos données sauvegardées :

bundle exec rake db:setup RAILS_ENV=production
bundle exec rake db:data:load RAILS_ENV=production

C’est tout, il ne reste plus qu’à redémarrer le serveur de GitlabHQ. Si toutefois ça ne fonctionnait pas, vous n’avez qu’à restaurer le fichier database.yml.old pour retourner à la configuration par défaut utilisant SQLite.

GitLabHQ et une bonne gestion des branches

Migration vers Git


Au travail, nous avons pris la décision de passer de Subversion à Git comme outil de gestion de sources. J’ai utilisé git quelques mois avant de migrer l’intégralité du projet pour tout le monde grace à l’outil git-svn. Et, mis à part les problèmes habituels de merge entre branches svn, j’étais plutôt enthousiaste concernant la migration vers git. L’idée était de disposer d’un outil plus puissant pour pouvoir séparer plus efficacement les développements en utilisant des branches. Pour expliquer quelle technique j’avais envie de mettre en place pour gérer nos branches de développement, j’ai cherché l’outil qu’il nous fallait, tout en espérant pouvoir migrer notre outil de gestion d’incident actuel (Trac) vers un se rapprochant plus de github.

Résultats

Il n’y a pas tant d’outils que je le pensais au préalable. J’ai trouvé gitorious, qui a l’air d’être un bon outil, mais l’installation à l’air complexe et ne propose pas (où je suis passé à côté) d’outil permettant de visualiser de façon graphique les branches.

Je suis tombé sur GitLabHQ, qui est un projet naissant, mais prometteur puisque l’objectif est de fournir une alternative similaire à github. Je l’ai essayé et je dois dire que je suis réellement très impressionné, à tel point que c’est maintenant un des outils que nous utilisons en complèment de Trac.
Nous utilisons toujours Trac pour gérer nos tickets de bugs et pour contrôler leur workflow à l’aide de messages de commit (il y aura un post ici à ce sujet dans quelques temps). Nous utilisons aussi le wiki de Trac pour la documentation développeur (nous n’avons pas encore pris le temps de la migrer vers GitLabHQ, ce qui arrivera certainement).
Continue reading