Agile software development, once the domain of
the daring few in smaller software shops around the world, is steadily becoming
the norm in larger enterprises. In a 2014 survey Actuation Consulting reported adoption trends of Product Development methodologies
over three years, from 2012 to 2014. In 2012 just 12.83% of survey respondents
identified their development methodology as Agile. 52.5% indicated they blended Agile &
Waterfall methodologies, and 18% were squarely in the Waterfall camp. Flash forward to 2014 and the survey reports
a drastically different split. Agile
development was the method of choice for 33.16% of respondents, a little more
than 2.5 times 2012’s number. Organizations with blended development
methodologies dropped by almost 15% and Waterfall only groups fell by more than
43% to 10.2% of respondents.
A quick Googlin’ will show you that the results of this survey are not an aberration. Agile development has matured as a both a movement and a set of practices over the last 15 to 20 years. The benefits of adoption have been voluminously documented. The core concepts have been refined and are well understood by an ever growing population. The frameworks and tooling that enable and ease Agile Development practices are many and full of features that maximize the already considerable velocity and quality gains associated with adoption. Agile Development is battle tested and has proven worthy of implementing at scale.
Unless, of course, you are talking about database development in support of applications. While a wealth of guidance, proven implementation patterns and tooling have sprung up in support of Agile Application Development there has been very little activity around the database. There’s a simple explanation. Data is precious, valuable and crucial to the business. The platform that holds this data must be carefully considered and deliberately managed when it comes time to make changes. These activities take expertise, artistry and time. DBAs have been the guardian caretakers of this resource and the service they provide is invaluable and irreplaceable.
Unfortunately this doesn’t change the fact that application releases are coming faster and faster out of development, spurred on by the business’ requirements to be more responsive to the market. Application developers are riding this wave, but DBAs are squarely in the path of this deluge without the proper processes or utilities to navigate these swifter waters. Agile Development advancements must now be viewed through the lens of the data platform. Agile patterns must be modified to accommodate the more sensitive and tricky nature of Database Change Management. The appropriate frameworks must be developed to provide similar yet safer acceleration in the deployment of database change as those that accelerate application releases.
Sign-up for our webinar, “The Agile Database: Best Practices” on Wednesday January 21st at 12:00 EST . We’ll dig deeper into this dilemma and explore the steps necessary to extend Agile Development practices to your Database. Among the topics we’ll discuss:
- Database versioning - Applications are ephemeral and can be replaced wholesale. They can be simply and easily versioned in a single spot. Databases are the sum total of all changes that have ever been made over multiple application releases. They can’t be easily “blown away” and determining the current version can be a job for Sherlock Holmes, unless you take a few steps to track deployment history.
- Concurrent Development & Release Packaging – For DBAs working in application teams with multiple streams of development happening concurrently, keeping track of what changes have and have not been applied can be a tedious and error-prone effort. Extending branching and merging concepts to your database scripts can make this much, much easier.
- Automated SQL Code Quality – Application developers enjoy a plethora of static analysis tools that catch common bad practices or violations of organizational best practices at build time. These tools reinforce and reward conscientious coding activities and increase long term code quality across releases. DBAs often perform this same task manually for the SQL scripts that make up application releases. With change velocity increasing, manual review of SQL won’t scale.
- Release Simulation – Too often, SQL scripts that work in one environment fail in downstream environments due to differences between the two. With a little effort, simulating releases prior to deployment in sensitive environments can greatly reduce the risk of firefighting during your maintenance window.
- Deployment Automation – For many organizations, deployment of the application and the database changes that support it are lightly coupled or disconnected altogether. By using the same build and orchestration tools to deploy your database changes that you use for your application releases, your team begins to act in concert with a common goal of deployment success.