Continuous delivery meshes well with agile development: Both facilitate the need to move quicker and deal with ever-changing requirements, delivering the best quality possible but usually with not enough resources. Agility is what is expected from technology companies and IT divisions. So, what does it take to have continuous delivery in your database?
Research done by Perforce Software reveals interesting information about the popularity of continuous delivery (CD). The infographic based on the corporation’s findings from a Q4 2013 survey shows that 65 percent of the responding companies are in the process of using continuous delivery for their projects. But even more interesting is that 46 percent of the organizations are worried that their competitors are using CD to get ahead.
This is exactly why agile development was born: the need to move quicker and deal with ever-changing requirements, delivering the best quality possible but usually with not enough resources. Waiting six months until the next rollout or release is not acceptable in today's market. Waterfall methodology's big release concept doesn’t cut it anymore. Agility is what is expected from technology companies and IT divisions. So, what does it take to have CD?
The Two Basic Truths
Having CD relies on two simple truths. First is automation. Automate every step in building, testing, promoting, deploying, documenting, etc.
The second truth, which is a requirement for automation, is version control. All changes must be documented and stored in one place, available for the automation processes. The automation processes retrieve information only from the vault and no other location. Everything that was checked into the vault can be promoted, provided it passed all the steps.
With this in mind, we have to find a way to control versions of all the application components—which can be native code (C#, C++, Java), database code (schema structure, PL/SQL or T/SQL, application parameters stored in lookup tables), or configuration files.
The Missing Piece in Version Control
There are several types of version control solutions. The most common solution is based on files. All the artifacts are files. They can be simple text or XML, or even an image.
The second type of version control is application-dependent, like with Informatica—all changes being done within Informatica can be versioned within Informatica. Changes that are related but external, such as database procedures, are out of the scope for Informatica version control.
Including the database within the application version control is not new. Until recently the solution that was available was to use the file-based version control tools to manage scripts that alter the database objects. The main challenge within this method is the application is tested using a real database environment and the changes being promoted are taken from the file-based version control repository, so they can be out of sync.