Automated Database Deployments is rather disruptive. But it is disruptive in a good way. Depending on the company, database deployments could be a "wild west" process where every team has their way of deploying changes. Getting any sense of consistency is going to be difficult. When I was working on
Tag: Continuous Delivery
Continuous Delivery allows us as developers to respond quickly to feedback to ensure we are meeting the business needs. Being able to respond quickly to changes the business needs without putting underdo strain on our resources will help us deliver value to the company and by extension our customers.
A while ago I was assigned to a project to move all of all the business logic from Oracle packages into C# code. Before I could even start moving the code I had to create a suite of tests covering those business rules in the database. The Oracle packages read
Small releases shouldn't cause major outages. It certainly shouldn't take down a production database server. In the end it was one line of code. That exposed several flaws and brought down the database server.
Wednesday night my team and I deployed a release to production. The release consisted of both
Nobody likes getting called at 2 AM. But it happens. More often than not, the reason for that page will have something to do with the database. A SQL job failed, a stored procedure didn’t get deployed, a missing index on a table. That problem doesn’t seem to