For companies developing applications, one step is often the most painful: managing database changes. In fact, anything to do with creating and managing databases can be painful. It involves a lot of manual labor to make sure database changes are in sync with application changes. Managing and deploying database updates is by far the slowest and riskiest part of the application-release process. This is why an IT cottage industry, led by Quest Software and others, has been so successful in providing third-party database management tools that make life easier for DB admins. In this eWEEK slide show, Pete Pickerill, co-founder of Datical, discusses the pillars of effective database automation. These data points represent what is required to bring database change management practices in line with modern app development and IT operations practices.
Keep DBA and Devs on the Same Page at All Times Changes in the database are often made by both the application developer and the database administrator (DBA). The application developer typically has a good understanding of why a change is being made and the impact that change will have on the rest of the product. However, this is not the case for the DBA, the person who is actually handling the change. DBAs are simply informed that the change is necessary and hope they deploy everything they should and don't deploy anything they shouldn't.
STEP 1 in DB Change: Tightly Associate It With Dev Effort The first step in packaging a database change is to tightly associate it with the development effort it supports. By tying changes to their features, DBAs are able to associate the activity with the driver more quickly and trace whether or not all of the appropriate schema components for an application change have been applied.
The second step of packaging is then tying the features to the appropriate release vehicle. This allows DBAs to better understand and participate in the application release process, especially as modifications to the established plan are made. If all changes are tightly associated with their feature and release, it becomes much easier to move those features in and out of releases without missing anything or grabbing too much.
Validation is focused on implementing automation with a human touch. This speeds the process of change validations without sacrificing the safety inherent in manual reviews. Recovering from a bad database change can be difficult, if not impossible. To avoid making a bad change in the first place, there are two levels of validation that must occur. Over time, databases serving the same application can drift out of sync due to their persistent nature and the manual process of updating them. To compensate for these possible differences, the first layer of validation should confirm that the database is in the appropriate state to successfully receive the changes.
