“If agile has been around since the 1990s and DevOps tools since the late 2000s, then why can’t our database development catch up with our application development?”
Are people in your organisation asking that question? Are you one of them?
Indeed, what’s taking the database so long? Why has database development been slow to adopt agile, DevOps, continuous delivery tools and continuous integration? How can an organisation move its database change management into a DevOps pipeline and efficiently bring about continuous database operations?
So, why is database development different from application development? The short answer has to do with database state and the rapid rate with which data changes.
Businesses rely on databases and can tolerate little risk to them. Suppose a change to some application code that goes out in a code release, then must be rolled back to last week’s version due to a code defect. IT can do that without losing any data. But a change to stored procedure or a SQL statement is deployed in the database, so will likely impact the data.
Restoring back to last week’s database version from a backup could mean losing a week’s worth of transactions.
With all this complexity and risk, you might argue the case for keeping things as they are, but there are many consequences of not changing the status quo, including your inability to release application changes faster than your database release process allows. This can lead to the inability for business to react to market changes or competitive threats fast enough which could lead to loss of revenue and market share and potential loss of customers.
But, what if it were possible to develop and deploy high-quality database changes faster, together with application changes, in a converged pipeline, without having to make compromises?
What if it were possible to monitor and identify performance issues throughout the DevOps pipeline before going into production, so that database releases are reliable and under control?
What if it were possible, once schema changes are deployed in production, to automatically replicate them to other database environments in near real time?
That would remove your database change management bottleneck, improve the quality and performance of your database code and synchronise your application and database releases.
When organisations become serious about integrating database development and change management into their DevOps pipeline, the result is continuous database operations.
With database DevOps tools from Quest, you can accelerate the process of developing, testing and releasing database changes. You can also monitor the effects of those changes on performance and replicate them to offload databases. Quest provides an easy path to bring the pace of database change management into parity with that of application development.
To find out how you can integrate your database operations with DevOps, visit www.quest.com/solutions/devops
Very Nice blog Post