Modern application development teams are aligned to deliver software using agile methodologies and a DevOps approach. Agile and DevOps are not the same thing, but they work well together to improve the application development process enabling quicker and more frequent delivery of software.
Agile versus DevOps
An agile development methodology involves the organization of the team and goals such that software development is iterative, incremental, and evolutionary. Using an agile approach, development and testing activities are undertaken concurrently, unlike the traditional Waterfall development model. Large software projects are broken into pieces such that immediate value can be delivered quickly, in smaller pieces, instead of waiting for a monolithic product to be completed. With continuous testing and integration, the smaller software pieces can be integrated into a larger, final deliverable.
DevOps is relatively a new term, coined in 2009, defining software engineering practices that combine software development (Dev) and software operations (Ops). The general idea is not really all that new, but the adoption of agile techniques and modern tooling to automate software delivery is. The goal of DevOps is for developers and operations personnel to collaborate throughout the entire service lifecycle, from design through development and into production.
A DevOps approach results in small and frequent code changes that can significantly reduce the lead time for changes, lower the rate of failure, and reduce the mean time to recovery when errors are encountered. With such benefits that can accrue, it is no wonder that DevOps and continuous delivery are gaining in popularity. Today’s development organization migrates more frequent changes into production than ever before.
Instead of long software development projects that may not deliver value for months, or perhaps even years (such as are common using the Waterfall development methodology) an agile DevOps approach delivers value quickly and incrementally over time. This is the primary reason for its quick rise and ascension as a software development methodology.
Culture and Automation
But what is required to succeed with DevOps? To successfully adopt DevOps requires a cultural shift within your IT department. The mindset must change throughout the IT organization, from the top to the bottom and within all disciplines.
Because DevOps relies upon incremental development and rapid software delivery, your IT department can only thrive if there is a culture of accountability, collaboration, and team responsibility for desired business outcomes. Creating such a culture is not easy.
Enter the DBA
From a database perspective this means that DBAs must work more closely with development teams. As developers are tasked with driving more and more frequent code drops, the DBA must be part of the development team to understand the process and to assist with turning over the database changes required to support each release of the application.
Application delivery usually involves copying code and executables from one environment to another. By contrast, the database is an entire configuration in each environment and changes get migrated. Each environment (Test vs. QA vs. Production) might be different, however so slightly. And differences can drift in due to things like performance optimizations, emergency changes, and so on.
To succeed in the rapid fire world of DevOps, DBAs must embrace automation tools that can be accessed and used by both developers and DBAs. For example, database change management should be requested by developers using a tool that can implement the change. The tool should also have the ability to review requests against standards and rules to eliminate poorly designed or inappropriate changes.
In a test environment, complex changes that drop and re-create structures may be tolerable because business users are not impacted, only other developers. But trying to do the same thing in production can cause a significant outage and perhaps even data loss if performed improperly.
When application changes rely on changes to database structures, these changes should be tightly coupled to the application changes that drive them. If the program code expects a new column to be there to function correctly, then you do not want the new code to be moved to production without the new column… and the opposite is also true. DevOps for the database must include not only making the changes, but also backing them out when necessary.
All of these important aspects of database change management are required, and without automation they must be handled manually by DBAs. Unless these DBA tasks can get intelligently automated a DevOps approach cannot succeed.
Why do I say this? Well, there are two primary reasons:
- If developers are given carte blanche access to make database changes without oversight and without training them to gain the experience and knowledge of a DBA, then poorly designed databases are inevitable as changes accrue.
- If automation is not implemented and the DBA must continue to manually review all changes, then the process will slowdown and the speed benefit of the DevOps approach will not be achieved.
If we believe that the DBA’s expertise is vital to a well-designed and efficient database application – and we should believe that – then we cannot do without DBA review. But we need that review process to be faster to keep up with the development speed. This means tools that automate and speed up the DBA review process are an integral component of database application development in a DevOps environment – just as tools like Jenkins, Puppet, Docker, Kubernetes, etc. that automate the development process and lifecycle are integral to DevOps.
Database change management is but one aspect of DBA automation for DevOps. Consider application packages where access paths are determined at bind time. Database access paths are determined for each database environment in which the program is to run and they cannot be copied from the development environment to production, for example. Without a way to examine access paths for accuracy and expected performance, problems will arise. This is another area where automated tooling can be used to compare and contract new access paths to previous ones, mimic Production statistics in Test, estimate performance, and alert developers and DBAs to problem SQL that should be tuned… hopefully during the development process instead of waiting until the software is delivered to Production.
The Bottom Line
As the continuous delivery model for applications continues to gain momentum and acceptance, a tighter integration between application and the DBA group is required. Integration and expertise is required both at a technology level and at a personnel level. DBA-level expertise is needed on development teams to help guide and implement changes appropriately. Implementation of automated software that combines application and database changes is imperative for DevOps success. Furthermore, automation of all of the database and software development and delivery steps is crucial and required for database-enabled applications using DevOps practices and procedures.