|By Pete Pickerill||
|February 6, 2014 02:15 PM EST||
In my first post in this series, I discussed the underpinning principles of all DevOps patterns as eloquently stated by Gene Kim, author of "The Phoenix Project." In this post I'd like to dig a little deeper into The First Way. As a refresher:
The First Way: Systems Thinking - This Way stresses the performance of the entire system of value delivery. Instead of becoming laser focused on the part of the process for which an individual or team is responsible, the individual or team works to understand the entire process from requirements generation to customer delivery. The goal is to eliminate the delivery impediments that arise when a project transitions from one isolated silo to another. Understanding the entire system allows business, development, and operations to work towards a common goal in a consistent manner.
When we started Datical, our first step was to perform extensive market validation. We quickly learned that database schema management was going to be tough nut to crack. In the scores of conversations we had with people throughout the ALM spectrum, we learned that the process for managing and updating the database schema that supports an application was at best murky and at worst a black box. So how do we elevate a process owned and understood by a few people in an organization to the level of visibility required to understand that process as part of a larger system?
What follows is a list of concepts pertaining to System Thinking that we've rallied around in providing our database change management solution Datical DB. Instead of the black box, database change management can become a transparent and flexible part of your value delivery system.
Start With Reality
When beginning a new project based on previous development, don't rely on a stack of SQL scripts on a file server or even in a source code control system. As you know, databases evolve over time and sometimes out of process changes happen. When a database schema is modified to resolve an error condition or performance degradation, these alterations are usually handled in a support ticketing system. You can never be certain that they were added to the stack of scripts used to build out a fresh environment. In light of this, any database change management solution should start by generating a baseline from the working system: your production schema. This ensures that design and development activity are taking into account not only those schema objects generated in Dev, but also those which originated in other stops in the system.
Don't Script! Model!
To keep this blog post short(er) I'll point you now to a blog post I wrote a few months ago on modelling vs. scripting.
Version Twice, Deploy Once
The first level of versioning any database change management tool should provide is versioning of the gold standard. Versioning the scripts or model that you use to build a fresh database instance for your application provides a ton of benefits. You can track how your schema has evolved over time and across releases, you can tightly couple a schema definition to the version of the application it supports using the same branch/tag/merge workflow that you use for your application code, and you can quickly stand up a new database instance that you know is correct for any released version or experimental branch you are working in. The second level of versioning takes place in each database instance. Tracking the version of the schema deployed on a specific instance makes deployment and troubleshooting much easier. Will this application build work with the schema on this instance? What changes need to be applied to this database to catch it up to the latest version? Were the right changes applied to this test database to validate a closed defect? If you are tracking the individual changes applied in a database and the impetus for those changes, these questions can be answered quickly and easily.
Unify Your Modes of Delivery
We've found that a lot of uncertainty was generated when database updates were handled by several individuals using their own tools and methods to affect the required changes. To remove this uncertainty, all database change must be executed using the same tools and processes across departments and individuals. The tricky part: a continuous integration system has different requirements than a developer working iteratively or a DBA processing a batch of changes in a headless environment during a maintenance window. In order to unify your database change process, the solution you use should be accessible to all of these individuals while maintaining the consistency of deployment activities. That's why Datical DB provides a rich GUI experience for developers that helps them craft & deploy changes in dev environments; tight integrations with popular build and release automation frameworks that preserve the frameworks' workflows while providing Datical DB functionality; and a command line interface that allows users in headless environments to deploy changes in the exact same manner that the GUI or a 3rd-party integration would. By unifying the modes of delivery you are constantly testing your release practices. By the time the production push rolls around, your system works.