Database Versioning: The ignored aspect of version control.

Version control is an important aspect of writing code. From the initial check-in to the final build, it is crucial to keep track of every change that is made to the code. Like stacking blocks of legos, you will find what started with a single brick evolving into a city. Databases, however are often ignored from version control. If you are lucky you use some form of ORM to connect to your database like Active Record. This will handle database migrations for you and provide database version control to some degree. However for legacy projects you are out of luck. More often than not I have seen the code managed very carefully with awesome branch and merge strategies implemented. Whereas all the database scripts simply dumped in a directly called SQL. Or if you are lucky there will be sub directories with stored procedures, tables and functions in their own directories. 

Continuous Integration: Going Beyond Builds

Establishing a build loop is the first thing you do when you install a continuous integration platform like TeamCity or Jenkins. You have a branch where a bunch of developers check in code frequently. They are bound to break the build often. You configure CI platform to pull code from your code repository via some trigger, probably at every check-in and then build the code. If the build breaks, you know exactly who broke it so everyone can go yell at the person till he fixes it. And that it where continuous integration seems to stop for most people. Like a rusted clock, it keeps on ticking and once in a while manages to tell the correct time. The original definition of continuous integration states it is the process of applying quality control in small chunks, applied frequently to improve the over all quality of the product replacing the traditional practice of applying quality control after the product development is done. Somehow this definition is lost in favor of finding build failures.