Without automation, CI/CD fails at database

February 21, 2022 | 3 minute read
Bhavesh Shah
Consulting Technical Manager
Text Size 100%:

Every application development project is undoubtedly also a database development project. A database is where data generated by applications is stored and persisted. But database development is fundamentally different from application development.

Database development includes several databases and types of changes, including database schema changes in the data definition language (DDL), PL and SQL, data, and configuration.

Providing a separate development environment per developer is a big challenge. So, most of the time development happens on a shared development environment. In application development, each developer can work on their local machine until they’re confident enough to push the changes to common version control repository. This process is the single biggest impediment in implementing continuous integration and deployment (CI/CD) for database development.

At times, rolling back a database change is a difficult proposition because database is stateful system, whereas an application is stateless.

No binaries exist in this process. Packaging a database change isn’t easy because each change must be applied directly on the database using the source code files. A change can’t be precompiled and packaged like application code. 

Benefits of database CI/CD

Despite these differences, best practice aligns database change management with application change management and doesn’t consider them two separate domains. Keeping both data and database schema changes up to date with application releases is paramount in today’s agile application development era.

The ability to package every change and create a history of database code changes in an automated fashion means that IT teams can also comply with audits in a simple and risk-averse manner. Through the automated testing cycles, IT teams can forecast impact before deploying changes, eliminating the possibility of disruption. Developers can quickly roll back to previous state if things go wrong.

The Oracle way: Visual Builder Studio

Oracle Cloud Infrastructure (OCI) Visual Builder Studio is a one-stop shop for all developer tools, including CI/CD. The recent inclusion of SQLcl tool in Visual Builder Studio makes it convenient to include database development in CI/CD best practices.  Visual Builder Studio can help overcome some of these challenges for Oracle database development with the following capabilities:

  • Build database objects in your development environment

  • Using Visual Builder Studio and SQLcl, we push the changeset files to Git.

  • In a test environment, download the files from git and run the changes.

  • Make changes to database objects on your development environment.

  • Push the changeset into a Git branch (fix).

  • Merge the fix branch into main branch after proper code review.

  • Apply the fixes into the test environment using SQLcl and Visual Builder Studio.

  • Roll back the changes.

Conclusion

As the video shows, Visual Builder Studio and SQLcl with Liquibase make the cumbersome process of tracking database changes a simple and easy-to-manage task. Try it out and make your CI/CD processes more inclusive, resilient, and agile.

Inspiration for this blog post came after reading this Liquibase article that talks about why without automation CI/CD fails at database. For more information, see the following resources:

Bhavesh Shah

Consulting Technical Manager


Previous Post

What is cloud sync?

Mike Chen | 4 min read

Next Post


Threat Intelligence Now Available in Oracle Cloud Infrastructure

Christa Scura | 4 min read