User-safe system configurations

As a developer and Linux-user, I continuously change several configurations in my systems, some of the changes can include:

• Port-based services: When you have several web servers working on the same machine, you have to configure ports and alias addresses.
• Package sources: I just don't want to mess my apt-get and slapt-get sources configuration.
• Security: External services configuration, security configurations and system restrictions.
• Run levels: I like to have the services I use at system startup, the other ones can burn in hell...
• Networks: I have some static configurations for some environments.
• X11: For some custom modifications I made for several displays.
• Databases: Sources, ports, users and some other configurations.
• Cron: Some backup and maintenance jobs.
• Revision control systems: Common filters, aliases, etc.

As you see, there are several configurations on my system, and I don't like to change them when a package gets updated, or when I upgrade my system. My usual alternative was to keep an .orig file for everything I was going to modify, but that didn't work very well, since I modified those files several times.

Because of the situation, I needed these things:

1. Keep snapshots of my configuration files.
2. Rollback changes.
3. Restore old configurations.
4. Check which files/lines where changed.
5. Use it all from the shell.

So, long story short, I needed a Revision Control System. And as I needed it just my local machines, I reduced my choice to Git and Mercurial.

My choice? Git, it is obvious that its shell interfaces are superior compared with Mercurial, it's very well integrated with all UNIXes and I have been working with it for a long time.

So, whenever I want to check if a configuration has been changed:

#> git status

What about reverting a change?

#> git reset -HEAD

And if I want to restore it to its initial version?

#>git reset

I just modified a bunch of files, save a snapshot of them:

#> git ls-files --modified | xargs git add
#> git commit -m "Too much work and no fun makes Jack a dull boy..."

Liquibase: Database change management

When you are developing an application, is almost sure that you will have to deal with a relational database system. And if you are developing with a 'refactoring' point of view, your database structure will change from time to time.

In many situations these changes have to be tracked and automatically applied for the different environments (development, integration, production) and I bet you are currently doing that manually, updating scripts and wiping databases back and forth.

This is no longer the case for me, a while ago I started using DBUnit for managing my database data changes, but as the development moved forward, the database structure changed as well. So we started looking for a tool that could simplify our lives.

Guess where we found it, in the DBUnit FAQ page, they even recommend it!. The tool is Liquibase, a java-based application that uses XML changesets to handle the database modifications, it works smoothly and support almost all productive database systems. It might be a little bit hard in the beginning, but it is worth it.

Distributed software development

As you have seen through the entries of this blog, I'm a distributed-stuff fanatic. I really think that the future of software development is closely related with this concept.

Many problems arise when you are working in a project that involves more than 2 developers, and the problems are even worst if new developers are included into the development process. It's a mess.

But you can make it work if you follow a simple goal: Every developer should be able to do whatever he wants without bothering anybody else.

This is very important when you are working in a database-based application, if several developers test their applications against a central database, you will have inconsistency problems in a matter of minutes.

I have worked in projects where this kind of problems arose more than once every day, it's a complete mess when testing and even worst when you are trying to integrate the work.

But not everything is bad here, I have also worked in projects where everything was meant to be distributed. Working with local databases such as H2 and versioning tool like HG or GIT. It's a big difference to be able to test all your changes without messing with other people data.

If you are working in a project with 2 or more developers, configure the project to be self-sufficient in all senses: Database, compilation, deployment, execution, tests.

Your development process will be shorter and the integration problems will be reduced, I can assure you that.