•  Comment

I just made a pull request for integrating Vert.x into Homebrew. You can see it here : https://github.com/mxcl/homebrew/pull/12227, when it will be merged, a simple brew install vert.x will allow you to enjoy this sweet framework.
  •  Comment

As our GitlabHQ setup at SRMvision is mean to stay, we wanted to migrate from the standard SQLite database to an easier to manage for us : mySQL.
The steps are quite straighforward, first, setup mySQL : 

create database gitlab; 
grant all privileges on gitlab.* to "gitlab" identified by "gitlab"; 
flush privileges;
Then prepare to dump the data out of GitlabHQ, stop your webserver, then, from your GitlabHQ folder : 
bundle exec rake db:data:dump RAILS_ENV=production
this will create a db/data.yml file. All you have to do now is reconfigure GitlabHQ to connect to mySQL and reimport the data. The database configuration takes place in the config/database.yml file, backup your existing file and rename the database.yml.example : 
mv config/database.yml config/database.yml.old
cp config/database.yml.example config/database.yml
Then edit the file to reflect your new configuration, only the production section is relevant in our case : 
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 # allows to autoreconnect if the mysql service restarts
  database: gitlab # to replace with your database name
  pool: 5
  username: gitlab # to replace with your credentials
  password: "gitlab" # to replace with your credentials
  socket: /var/run/mysqld/mysqld.sock # mysql socket location on debian
Once this is done, you have to create the schema and restore your data : 
bundle exec rake db:setup RAILS_ENV=production
bundle exec rake db:data:load RAILS_ENV=production
Job's done, you just need to restart the GitlabHQ server now (nginx, apache...). If you encounter a problem and this does not work as expected, you just have to restore the database.yml.old file to go back to SQLite.
  •  Comment

As I said in an earlier post, at SRMvision, we use feature branches to isolate our work and be able to publish it to our production environment with a clear change history.

One thing we use since the beginning (at the subversion time, pre-git era), is the control of our ticket tracker (Trac) from our commit messages. We have the following verbs to control our tickets (synonyms are available, but we rarely use them) :

  • see #NUM to link to a ticket
  • fix #NUM to close a ticket

Repository references to commits are automatically added into ticket's history in our Trac instance.

To be sure of the quality of our code, we set up a custom workflow in Trac. Once a dev/bugfix is done, we set the corresponding ticket to the "Testing" status. The next step is simple, either the test passes and the ticket is closed, or it does not and it returns to the developer. So, we added another verb to our commit handler : "test" to automatically set a ticket to the "Testing" status.

Our adoption of feature branches has forced us to rethink our workflow. Passing a ticket to "testing" while it is not even merged into our "testable" branch was really polluting Trac. That's why we added the status "Fixed on branch" to allow us to differentiate really testable ticket from not ready ones.

We finally adopted the following mecanism, keeping only our three verbs (see, fix, test) :

  • test on a branch other than master, ticket's status is set to "Fixed on branch"
  • on a branch merge to master, "Fixed on branch" tickets are reopened and set to "Testing"
  • on the branch master, test sets the ticket to "Testing"

On a classic development, we can have 50 "Fixed on branch" tickets that automatically pass to "Testing" once merged onto master. Using this technique allows us to check if every single ticket related to the feature has been correctly handled from development to quality testing.

If you want to deploy a similar technique in your environment, files we are using are available at the following address : https://github.com/CedricGatay/sandbox/tree/master/trac-git-hook

You will find the following files :

  • post-receive : git hook, to copy into the hooks/ directory of your "central" repository (the one connected to Trac), triggers delayed launch (1 minute later) of the next script (avoiding to block the commit),
  • trac-post-commit-hook : Trac hook parsing commit messages to control tickets
  • trac.options.ini : excerpt from Trac configuration file allowing to customize workflow

Please notice il will be necessary for you to edit script settings referring to git repository in Trac (called 'git-clone' for us) and paths corresponding to your environment.