The 3 ’esses’ of continuous database processes -- Speed, Scale and Simplicity
The driving force behind the shifts we’ve seen to Agile, DevOps and Automation, are the business needs of the companies we serve. Doing more with less and delivering it sooner than the competition is what differentiates leading companies from the rest of the pack.
Once a competitor delivers relevant features, which are faster and better quality, you WILL lose market share. In the age of Agile Development, enterprises must be capable of moving rapidly to deal with ever changing requirements, while still providing quality results, all while dealing with limited resources.
Avoiding manual steps when possible is the key to effectively master Agile sprint deployments and practice DevOps. The accurate and efficient implementation of deployment and process automation takes away the factor of human error, which comes about when manual steps and processes need to take place. It also allows for the process to be handled with high frequency.
Continuous Integration, Continuous Delivery and Continuous Deployment are the customizable common principles and practices to structurally handle the process of automation and set ground rules for the many participants in the development, build, test, and release of the software process.
The main goal of Continuous Integration is to streamline development and prevent problems. Avoidance and quick detection of complications through automated testing assures quality and transparency, ensuring the highest quality service.
Continuous Delivery becomes the next automation step after continuous integration. While striving to become efficient, lean, and more agile, we can start planning and making sure each change is "releasable" to make sure we always have a tested build ready for deployment. This allows us to always have a releasable version at hand, thus enabling timely releases based on business decisions, time-to-market, etc.
In case of a failure, we should get automated alerts for the problem, go back to development, and restart the cycle. Once the process is completed, a fully tested application is available to be released to production with a click of button. Actual deployment to production would be manually actuated, followed by rerunning of the regression test. The actual deployment to production becomes much easier with time, as all current and previous lifecycle stages have been tested and accounted for, significantly lowering risk.
Removing the human factor from the approval button comes with its risks, and it is not always a recommended practice for every business, but Continuous Deployment takes the next step of pushing changes automatically to production and running the concluding set of tests there.
By automating "everything" and moving tested, focused updates and process "upstream", we look at better service, happier customers, and better bottom line.
Measuring Success
Success from continuous processes is usually clear, and focuses around these areas:
- More rapid changes -- being able to react quicker
- Less changes backed out -- higher code quality, quicker time to market
- More stable releases -- less defects making it out to end customers
- Better collaboration between Development and Operations (DevOps…)
Database Continuous Delivery
Continuous integration, delivery, and deployment require a strong and sturdy database version control, safe deployment automation, a clear work process, and automation of that process. When implementing database continuous delivery, we must ensure that we cover these four bases:
- Enforced database version control. This makes sure all database changes follow a mandatory documentation process, so we can always know who did what, when and why. This guarantees a single source of truth for all the database development assets and is a basic building block for the rest of the process.
- Using task based development assists in associating each introduced change with a change request, trouble ticket, or a work item. Later deployments can rely on this information to help decide what changes need to be shipped as part of the pending release and what changes have been postponed.
- A baseline aware deployment helps us safely understand what changes should be deployed. More importantly, it makes clear which changes should be discarded, so not to overrule important changes already deployed by other teams, or override hot fixes to production.
- Automation interfaces (web-services, command line API, etc.) are a must in order to create a harmonious process, dealing with database changes as part of the whole picture, tightly coupled with the delivery of Java or .Net code changes. Being able to raise red-flags and "stopping the line" automatically if required is a mandatory step for continuous processes. The last thing we want is to blindly push changes to production – so getting an alert that something does not follow our safety assumptions, can make the biggest difference between sleeping tight and having nightmares.
The solution for the challenges that automation presents can be found in the form of Continuous Delivery and DevOps for database. Traditional tools are both inefficient and risky to automate and actions of the database are unaware of each other.
Database Continuous Delivery, while following best practices of change management, enforces a trackable single change process over the database and eliminates the risk of code overrides, cross updates, and merges of code while plugging into the rest of the release process.
Image Credit: Ermek/Shutterstock
Yaniv Yehuda
is the co-founder and CTO of DBmaestro, an enterprise software development company focusing on database development and deployment technologies. Yaniv is a DevOps expert who spent the last couple of years raising awareness about the challenges surrounding database development and deployment, and how to support database Continuous Delivery.