Continuous software development and delivery requires good communication between all teams involved and a well-chosen database management tool with features that the extended team finds valuable.

DevOps and the database management features needed for continuous, painless deployments

The numerous steps and components that compose a software release are the very items that make releases difficult to automate. Another complicating factor is the timing of releases or how often they're scheduled to occur. When releases happen more frequently, as in a continuous development process, the release process has to be smoother and less painful than in typical software development and delivery.

The other factor to consider is the working relationship between developers and those who perform the release. Whether you call release professionals support, production, services, IT, implementations, or DevOps, the important thing is how the two groups interact. It also matters which features within a database management tool will help make a release successful and efficient.

How to Build a DevOps Toolchain That Scales

Resource relationship management

Historically, smooth relationships among application developers, testing teams, and the release team either never existed or involved a "dump and run" style that turned into an endless struggle as each team left the others with problems to fix. With every release, these communication and workflow problems were repeated.

The process of building a working relationship starts with developers. Application developers need to meet, discuss, and plan with production release personnel to verify that the database, documentation, and hardware requirements work for the existing production system. The earlier that discussion starts, the better. Keeping both parties updated throughout the release is essential, because requirements and application code change repeatedly throughout the development lifecycle.

When you communicate explicit application development details to release resource teams, you reduce the risk of surprises. In other words, release personnel can plan and build the release in a way that reduces conflict later on when it's pushed into production. One way to do this is to test the release process before the real release is deployed on the QA server—a test release can be built with the current application code, hardware, and configuration. Release personnel can then verify that the release process works as expected before the production deployment. Calm, effective test releases between developers and release staff create a respectful, professional relationship between the groups. The fewer last-minute architectural discrepancies or unwelcome surprises, the smoother and less stressful the release will be for both groups.

Continuous delivery is only successful when a positive working relationship exists. It's not magic because it's continuous. It's magic because the two groups create an effective relationship. Development teams must communicate effectively with release personnel regardless of the software development methodology used.

Features that create efficiency

Creating effective releases typically requires a database management tool. Database changes are the biggest sore spot between development and release. Any time a database is not updated properly to reflect new code changes, the database is out of sync and the deployments fail.

There are several features that make using a database management tool useful when releasing deployments. In order to deliver painless deployments, a database management tool must do the following:

  • Offer a vendor-agnostic system so schemas don't have be changed if you switch database vendors
  • Support multiple code check-ins and merges, preserve the semantic meaning of the database fields, and generate the documentation automatically (Granted, automatically generated documentation may not be complete, but at least it provides a foundation on which to build.)
  • Use a single log location that includes changes to the database as well as the application code
  • Provide the ability to invoke the tool from the command line so it works with automation
  • Support a variety of target databases and structures
  • Allow automatic database upgrades with scripts that are started manually
  • Allow application code and database code to be checked in iteratively or simultaneously

Prioritize feature needs

The final steps are to prioritize the features your business requires in the database management tool and then find the tool that works for you. Be careful to include all parties involved in the conversation around required features, including the process of ranking these features. Development and release personnel, or leaders of each group, need to be involved in this prioritization. Each group knows what aspects are most important to them and which ones help ease release pain.

By including this larger team in the features discussion, as well as in the eventual tool choice, you instill good will among all your DevOps personnel. Be realistic. Developers are going to have to like the tool, and release personnel must also find it valuable; otherwise, they simply won't use it.

Now the fun part: find the tool that meets your needs, and make sure the tool meets one or more of your feature requirements based on the priorities the team has identified. It may be valuable to have the team suggest tools they've either used in the past or that they believe will work based on their knowledge of the hardware and software systems in play. Keeping the full team involved in the entire process is important to creating a highly functional DevOps capability.

Topics: DevOps