Database CI with Jenkins and DBmaestro
Market demands, customer requests, competitor actions and business decisions, all require extremely fast software delivery. DevOps, and specifically Agile development, Continuous Integration, and Continuous Delivery are therefore being implemented by an ever-growing number of organizations.
However, in order to effectively master Agile sprint deployments and practice DevOps it is crucial to be able to implement deployment and process automation internally, within development and QA, all the way to production.
The frequency of deployments is projected to double by next year and manual steps can’t scale nor follow the required frequency of changes. Therefore, solutions like Jenkins for build automation and application release automation (ARA) tools like CA-release automation, IBM uDeploy, Puppet, and Chef, are being effectively implemented and returning on their investments with dividends.
Jenkins is used to orchestrate continuous integration processes, from running the application builds to deploying the application binaries in the test environment, to running the tests, and so on.
However, the database requires dealing with different challenges than application code. The database, unlike other software components and code or compiled code, is not a collection of files. Thus, Continuous Integration & Delivery for Database has taken a back seat to source code, leaving database automation to play a game of catch up at a high risk.
Currently, Jenkins manages processes which deal with code build automation, but your database processes are handled manually. A great example of how such a hybrid process works in practice can be visualized in the timeless chocolate scene from ‘I Love Lucy’
In our analogy, the conveyor belt represents Jenkins, the chocolates signify the application code, and Lucy and Ethel are ‘handling’ the database code.
This model clearly can’t work at the necessary scale or frequency and needs to be addressed in order to meet the demand.
The DBmaestro DevOps Platform – Jenkins integration allows you to add your database deployments safely into your continuous integration and continuous delivery pipeline. Jenkins can invoke DBmaestro DevOps Platform’s API when automatically generating database upgrade SQL scripts, executing database upgrade SQL scripts, applying label, checking-in the changes in the target environment and other related actions.
The Jenkins-DBmaestro integration enables true database CI and continuous delivery commensurate with application code best practices . It will also bring the database up to speed with native/application code integration.
Following the same proven processes for your database, as you do for your code, enables you to bring effective automation and Continuous Delivery to the database. This breaks down silos between development and operations allowing a fully integrated, streamlined, and rapid database lifecycle management.
In this article we will overview how to create a fully automated process by embedding database builds with your application build and running database upgrade SQL scripts as part of the database CI process, marshaled by Jenkins.
After installing DBmaestro and configuring the environments you wish to manage, you can easily add the DBmaestro-Jenkins plugin and build your database automation into your Jenkins jobs with a few simple steps.
First, you need to configure the DBmaestro-Jenkins plug-in with several global parameters, such as the name of your database and authentication method. Then you need to decide if you want to use an out-of-the box build and deploy ready-made scenarios, or tailor your own specific scenario and build/deploy logic with the Advanced Commands.
Once you have configured these global parameters, you can add DBmaestro DevOps Platform build steps to your Jenkins processes (you can override these global parameters with job specific values, so feel free to experiment ☺)
The next step is to add your database build and deploy logic into your Jenkins jobs in order to create an overall code + database end-to-end process.
Here is where the fun begins.
You can use an out-of-the box build and deploy ready-made scenarios to quickly build database changes based on tasks, latest revisions, or a specific label and then deploy these changes to the next environment (i.e. – Dev to QA, QA to Pre-Production, etc.). You can also easily validate your environments to a specific configuration (a baseline) and automatically get alerts for any configuration drift that might occur. (If someone changes something not according to due process, you want to know about it, and make sure it doesn’t break your next deployment).
Alternatively, you can tailor build you own custom logic with the advance commands, using them as building blocks. Just add objects to source control, apply labels, set a baseline, check out and check in objects, create deployment scripts based on tasks, revisions, and specific labels, and execute them on the target database.
How Would that Look in Real Life?
Example I: Accounting application processes using out-of-the box DBmaestro DevOps Platform scenarios
Accounting APP – BUILD process
Accounting APP – Deploy process
Example II: Trading application processes using custom build DBmaestro DevOps Platform scenarios
Trading APP – BUILD process
Trading APP – DEPLOY process
Database CI and CD Made Possible with Jenkins and DBmaestro
Failure to properly implement continuous delivery means the database will keep lagging and eventually you can find yourself in a difficult situation. Database continuous delivery can be a relatively simple process, leading to increased productivity, faster time to market, reduced risk for new releases, and higher quality with fewer bugs.