Automated Deployment changes of Databases as part of CICD pipelines

What is Continuous integration and continuous delivery (CICD). 

CICD pipeline is a sequence of different steps which is continuous, and which creates automation in the software development and deployment cycle. A software goes through various stages in its life cycle. It automates the whole software delivery process which includes building code, testing the code (which is continuous integration) and then deploying the code for end user. It automatically removes the possibility of manual error, and it creates a continuous loop that can take feedback and make changes to the software and then deploy the new code without affecting the availability to the end user. 

Continuous integration- it is a set of practices for software development where all the people working on the code merge or combine their own code on a repository commonly used by everyone multiple times. Continuous integration creates an automated sequence which executes building and testing the new changes in the code and then gives feedback to coders of any problems or if the code is working correctly. 

Continuous Delivery- it creates an environment in the software cycle that consists of many stages which automates the process of software delivery. Continuous delivery automates the process of deploying or pushing changes of the code to the deployed environment without affecting availability. 

CI and CD both are an integral part of software development lifecycle automation. Both help to automate and increase the speed from starting of the project to deploying the software to removing bugs and errors and updating it.  

Automating database changes as CICD pipeline. 

There are lot of automation procedures and practices defined to manage the software development lifecycle, but there aren’t many adoptions of automation with respect to changes in databases. Every organization needs data along with software to run. And database changes need to be made in order to update software or add additional features to it by changing the schema of database or adding any tables to the database. Generally, if there is any change in the software with respect to database access, it takes a lot of time to do it. Because first the software team will identify and inform the database administrators about the changes to the database. Then the DBAs will make the changes in the database whenever they are free from their ongoing projects. This may consume any amount of time. Then DBA will inform the developers about the changes. Then the developers will either approve the changes or give feedback for correction and again the same process continues. This is the reason why database changes are tedious work.  

The first step to automating database changes is source control. Every change in the database can be represented with a code (for e.g., SQL query). This query can be stored on a git repository.  

After this, it tis the time to work on continuous integration. In this step the database changes are automated, and validation of the changes takes place. We can use batches which can reduce the risk of losing data or by mistakenly altering the whole data. 

The last stage is continuous delivery. In this stage, the database changes are delivered to the stored environment. This is an essential step in database change and after every delivery, all the softwares connected with that database needs to be verified if the delivery has any effect on them.  

Generally, companies have parallel application CICD pipeline and a different database change pipeline. But the more effective method is to have combine them both in a specified way.  

Software and Database both must have code stored in same repository and must have same shared CICD pipeline. It must be synchronized and any changes in either software or the database must trigger the pipeline and do all the changes automatically. This will solve the problem of slow database change and the speed of software development and deployment process will increase many folds.