4 Reasons Why You Need Visibility Into Database Deployments
The database is a bottleneck to application deployments. A recent CIO Magazine survey showed 91% of Database Managers and 90% of Application Development Managers agree. By gaining insight and visibility into the process by which your database deployments are made, you gain a huge amount of benefit.
1. You can’t avoid what you can’t see.
We slow down when we are driving in fog. Because we have limited visibility, we have less time to react to danger. The same happens in software deployments. We don’t understand the impact database changes will have on the application and this causes us to move slower. What if you had radar in your car? It could warn you much earlier of obstacles or hazards. In turn, you would have better visibility and be able go faster. The same is true for database deployments; with more visibility into the impact of change you’ll be to see and fix problems before they become issues and deploy changes faster.
2. You can’t improve what you can’t measure.
We track every bit of code as it moves through the Software Development Lifecycle (SDLC). Because of our metric gathering from user story creation, estimation, builds, deployments, we can identify exactly where in our application development process we need to improve. If we see a large number of build failures that are delaying application artifact delivery, we can easily determine the issue and remediate it.
We simply cannot do the same with database deployments. Typically, when a database deployment is needed, someone will create a helpdesk ticket for the DBAs. We may attach a SQL script or describe the change in the ticket body of the ticket. And then…we wait. Without insight into how long it takes to accept the ticket, review it, approve it, and schedule for deployment, the entire database deployment process is a black box. We don’t know if we should improve our acceptance speed or approval speed. Where does management need to apply more resources to improve our process? The answer is a shrug, which should terrify those with P&L responsibility for the business unit building the application.
3. You need to understand why your DBA’s tell you “No”.
A herd is only as fast as its slowest member. Luckily, we don’t have packs of roving wolves taking our sick and old at the office. Thus, we can’t rely on external forces to help us improve. By having insight into database deployments, you can see why changes are being rejected and integrate those learning’s into your development process.
Waiting until a Production maintenance window to find out if you proposed database changes are acceptable, is inefficient. By understanding in development what is acceptable to the DBAs allows development to avoid wait states and rework.
If your database team has standards, you need to know what those standards are so they can be adhered to. When expectations are clearly defined, those expectations will be met. However, I have seen instances of “DBA shopping” in companies with loosely defined standards and uneven enforcement. Development teams will seek out DBAs that are lax or inexperienced for especially complex deployments. Thinking that this will improve the likelihood of a successful deployment, the development teams will actually cause more work due to bad database changes being pushed to production.
4. Team work makes the dream work.
As software becomes more and more inextricably linked to business performance, it has become more and more complex. No one has complete knowledge of all software systems that a business relies on. This is seen in the software development lifecycle. The further left you are in the SDLC, the more knowledge you have of the application. The further right you are, you have more knowledge of the environment. By having insight into the later stage environments, especially the database layer, developers can help Production DBAs by delivering changes that will deploy successfully to all environments in the SDLC.
There will be times that database standards should not be applied to a specific change. For example, if a new column needs to be added with default values, most DBAs will reject the change. In the past, new columns with default values would cause a DML lock on a table while the default value is updated row by row. Furthermore, this sort of change can be viewed by the DBA as code smell; instead the DBA may insist that the data insert should be made explicitly by the application code.
By having visibility into database deployments, you can either understand the DBAs position and change accordingly or you can help the DBA understand the change is due to previous bad decisions and that this will help fix those. Either way, by seeing what your DBAs doing, you can work closer with them to resolve issues earlier in the SLDC.
To learn more about the importance of database deployments in the application release cycle read this white paper, Top 5 Warning Signs Your Application Release Process is Broken.