7 Best Practices for Database Deployment

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.

In many organizations, database deployments are managed by a team external to the application development team. Since the database and application must be released as a unit, this two-path approach to deployments is difficult to manage and can create serious visibility problems. While many developers don’t want to admit it, application deployments are very much everybody’s problem. Here’s why:

  1. Create visibility in all processes to anticipate problems
  2. Measure every bit of code change
  3. Automate database deployment to alert team members for problem
  4. Encourage your DBAs to tell you “No”
  5. Encourage hands-on application work until it’s in the hands of the customer
  6. Create the best team possible
  7. Bring DevOps to the database

Create visibility in all processes to anticipate problems

Limited visibility can increase the cost of database deployment and gives less time to react to problems. Without visibility, we don’t understand the impact database changes will have on the application, which causes us to move slower.

The same is true for database deployments. With more visibility into the impact of database change, you can see and fix problems before they become issues. This also has the added benefit of allowing faster deployments.

Measure every bit of code change

Teams should be tracking every bit of code as it moves through the Software Development Lifecycle (SDLC). With the proper tracking, a team can improve application development thanks to data from:

  • User story creation
  • Estimation
  • Builds
  • Deployments

Furthermore, if your team sees a large number of build failures that are delaying application artifact delivery, they can determine the issue and fix it.

The same cannot be said with database deployments. Typically, when a database deployment is needed, someone will create a helpdesk ticket for the DBAs. Then, the team may attach a SQL script or describe the change in the ticket body of the ticket. And then…there is a long 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. No one knows if the process needs to improve 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.

Automate database deployment to alert team members for problem

Developers are impatient. As Development moves forward to the next sprint, moving back to a previous sprint to fix a database update problem is painful. This not only slows the progress of the current sprint, but also forces dev teams to mentally switch to resolve the database deployment issue found by a Production DBA.

This difficulty could have been avoided with database deployment automation. The automation process could have alerted necessary team members that the DB change was not sufficient. Until then, we are going to have to deal with “out of band” changes and interrupts.

Encourage your DBAs to tell you “No”

By having insight into database deployments, you can see why changes are being rejected and integrate those learnings into your development process.

Waiting until a Production maintenance window to find out if your proposed DB changes are acceptable is inefficient. By understanding 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, there are sometimes 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 the lack of oversight will improve the likelihood of a successful deployment, the dev teams will actually cause more work. Without a knowledgeable DBA, database changes get pushed to production, causing more work down the line.

Encourage hands-on application work until it’s in the hands of the customer

If your application is not in the hands of the customers, they are seeing no benefit from your development efforts. Thus, there really was no point in your making those code changes in the first place. Moreover, application development requires feedback from the customer to improve. That feedback is impossible to receive until the customer has the application to use.

By relying on a slow, manual, error-prone process to update the database, you slow down your actual database deployments. You must automate the entire Application process, not just the application itself.

Create the best team possible

As software becomes more and more linked to business performance, it also becomes 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, the more knowledge you have of the environment. By having insight into the later stage environments, especially the database layer, developers can help Production DBAs. With this relief, developers can deliver changes that deploy 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 only by the application code

Bring DevOps to the database

One of the most integral aspects of database deployment is the culture of database DevOps. Companies that adopt DevOps have a higher market capitalization growth rate (total stock outstanding X stock price) than their competitors. DevOps adopters also outperform the S&P 500.

With DevOps, we’ve seen high performing IT organizations quickly attacking new markets and expanding rapidly in existing markets. If your company does not adopt DevOps, you will be looking for a new job because your company will eventually fail.

Development teams may look at database deployments as somebody else’s problem or a mere annoyance. But the truth is that the state of the database deployments of an organization can affect a developer’s paycheck. Thanks to database DevOps, jobs are now at risk due to competitive threats from other companies that are more agile from an IT perspective.

There is a solution, though. Automated database deployments or Application Release Automation can help. To complete the task, you must have your DB changes follow the same path as your application changes. That means:

  • Using the same source code repository for both DB and Application Changes
  • Providing lights out and single click deployments for all environments
  • Demanding immediate feedback to proposed database changes like you have for your code

If you have already applied these patterns to your application code, it’s time to bring the database deployment into the future the same way.

To learn more the role of developers in DevOps database read this white paper, Making DB Changes Easy for Application Developers.

Seeing is believing.