Every one and their dogs use Continuous integration today …
And thinking about the developers and companies that are serious about software quality, they use some sort of TDD or at least write the unit tests for the written code too …
Most of them, at least the one I’m working now, do peer review too (ok, this post does not apply if you are lucky and doing XP)

With this scenario the standard work flow is:

• Write the test
• write the code
• remember to run the test
• if the test passed commit the code to the central repository
• warn some one to do the peer review
• the reviewer checks out all changes from the central repository (your and any other commits )
• the reviewer looks at your changes (after he/she separates it from the other commits)
• the peer review asks for some changes
• you change the tests
• you change the code
• you run the tests
• you commit the changes to the repository

In this workflow we have a great problem …
During all the time in bold the code in the repository probably has problems, or is not yet revised by QA …
Other problems in the standard version control systems are for example:
You cannot access the repository, and cannot commit your work if you are offline, this will cause problems, because your next commit will have more than one change set, so, it will be harder to track what commit caused a bug for example

Of course this approach has benefits too, but if you are using it, you may know its benefits

The idea of this post is to propose a little different workflow, that need a different approach to version control …

The workflow described above is very close to the one used with a centralized version control system, like CVS, Subversion, …

The one I’ll describe, needs a Distributed Version Control System, like Bazaar and Git, I chose Git because it is very fast
I still use a central repository as you’ll see bellow …

• Write the test
• write the code
• run the tests
• if test passed commit the code to your local repository
• ask some one to do peer review
• the reviewer will push your version from your machine
• the reviewer will look at your changes
• if he asks for some changes
• change the test
• change the code
• run the tests
• if test passed commit to your local repository
• push your changes to the main repository

As you can see, this workflow is a little different from the previous one, and we have the following benefits:

• The commit, checkout, create branch, merge branch operations are a lot faster and cheaper because they are done locally
• The “central server” version has always a working version, because you only push your changes there after the peer review, this ensures the build server version is always ready for a demo
• The reviewer of your code pools directly your development branch, what makes easy to find your changes, the changes he/she needs to review
• Merge is really easy

Of course there are drawbacks too, for example:

• You need to learn another version control tool (if you are not using Git yet)
• There is no access control for parts of the repository, every programmer has all the version history of the source tree, but this is easily addressable if your permission system is by project
• In a DVCS there are more concepts than just commit and update, push is not the same as commit and pull is not the same as update
• There are no good GUI tools for Git yet

I have wrote another post about synchronous continuous integration here, and you’ll find a rake task to help you if you are working with Ruby too.

So, I think that is it.
What do you think about this approach? are you using some thing like this?

If you enjoyed this post, make sure you subscribe to my RSS feed!

• OpenOffice 2.0 - this one is very useful at speeches and trainings.
• 7-Zip - The best windows archive manager
• GVim - My Ruby On Rails editor of choice, I use it on linux, and now I carry it on my pocket to use when I’m in a windows machine, the only problem is that it was not compiled with omnifunc support, so it does not have code completion.
• Firefox - Simply because I can’t use IE, it is not for me
• Putty
• WinSCP
• VNC Viewer
• Sumatra PDF (A very lightweight PDF reader)
• VLC
• MPlayer

Now I can bring every thing I need with me (ok, almost every thing)

So, if you liked the idea, take a look at PortableApps.com download it, choose what software you want with you all the time, and be happy!

Versão em portugues aqui.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Versão em portugues aqui

I think that everyone agrees that continuous integrationis a need for any and every software project, but the asynchronous integration largely used has some problems, like:

• The code is commited even if the developer forgot to run the unit tests
• The tests are executed after a while on the integration server, only after that the team will know if the tests passed or not
• The developer is probably working on something else when he/she get the message telling that a problem ocurred with the build, and needs to stop what he/she is doing now to correct the error, or let the error on the repository for a while probably breaking the updates for other developers

I’m not telling that you should no have a build server, you will have a build server to enable every involved on the project to get the latest version of the application, and to generate reports about the source code, these reports usually take a long time to generate and you there is no need for the developer to wait this generation to start the next task, but I do not think that the integration of the developers work are the responsibility of this server.

In other words, you do no need an integration server, just a build server if you are using synchronous integration!

The ideal is that during the commit process, the developer update his source code to the latest version, then run all tests and only if all tests passes he can commit the code to the repository.

Of course you can improve this process adding some restrictions, for example a minimum test coverage, but in my case, I wrote this Rake taks for a project where I’m working alone, and I’m using GIT for version control (I’ll write a post about GIT this week if I have the time), I’m using synchronous integration in some Java projects too, in other opportunity I’ll write about this process in java projects.

I’m adopting this synchronous integration practice for all new projects in my company and in every client that likes the idea.

Back to this post subject, it is really easy to implement synchronous integration in a Rails project, you just need to follow this two steps:

1 - create a ‘git.rake’ file in the directory lib/tasks with the following content:

namespace :git do
  desc "Update every thing before the tests"
  task :update do
    puts "Lets update it all, but we are using GIT so we already have the latest source for this repo"
  end
  desc "Run all tests, if all are OK, then commit every thing to the git local repository"
  task :commit => [:update, :test] do
    puts "No test failures, now we can commit it all"
    exec 'git commit -a'
  end
end

As you can see, this Rake task is very simple, and I’m sure it will improve a lot your projects quality.

2 - at the and of each task, instead of running “git commit -a”, run the command: “rake git:update”

That is it! using that you are now using synchronous integration

Of course this Rake task can be improved, you can configure it to pull from a central repository, or update your source code if you are using subversion for example, but I think this one is already a good start point.

It all tests are OK, GIT will open VIM for the developer to write the commit message, and after that, the code will be committed with every thing working, and good bye integration problems!

And you, what do you think about synchronous versus asynchronous continuous integration? what approach do you think is best? why?

If you enjoyed this post, make sure you subscribe to my RSS feed!

I just found this great piece of software called TotalRecall ™, that records all calls in or out from my N80.
Ok, and why this title for this post?
Well, because I always forget the name of the attendant I was talking when I call any 0800*** number …
I forget the time of the meeting I have just scheduled by phone.

and things like that.
So this software is really helping me out.
(OK, I think that this capability should be built-in the phone, I do not know who was the “great” engineer that created a phone sound recorder that cannot record a phone call, does it sound as stupid for you as it sounds to me?)

A little review of the software …
Features

What could be better?
I have only two suggestions for them (in priority order):

1. enable the recording in MP3 instead of AMR
2. put the date and time of the call in the name of the sound file, besides the contact name.

The second thing I liked most was the price, it is just U$10 (at the time I’m writing this post).
So, take a look at their online store …

If you enjoyed this post, make sure you subscribe to my RSS feed!