If you’ve had struggles with database development and had a real world disaster, you could win in a new Redgate contest. We’re looking for the places where old style, waterfall, traditional database development has been a problem. Especially when application software developers have been adopting DevOps, small, rapid release strategies.

Enter before Mar 20 and give us your story.  Don’t worry, we’ll anonymize your name and company details. You can enter as many times as you like, but can only win once.

My Struggles

I started working with a small startup company that had 8-10 application developers. We tried to work in a rapid format, releasing a new version of our website every 2-3 weeks. This was going OK, but not great. Often we’d release and developers would go to test their new feature, only to realize that they’d forgotten a database component.

They would roll forward, finding code and deploying a database change during the release process, usually getting the feature working in 10 or 15 minutes.

Until they broke something else because they hadn’t really tested the database component complete. Or they realized they needed yet another database change. Or they had forgotten to code for some edge case that another developer tried during the release smoke test.

When I started, we all gathered in the office on a Sunday night and spent an hour or two releasing code. Not one of my favorite times.

The app developers were using source control, and trying to test, but they often sent code to QA and then fixed things in QA, forgetting that they needed to ensure those changes were deployed again to production.

Across a few months, we implemented what people would not call a DevOps process, reducing our release time to a few minutes, with myself and another developer on the phone, releasing automated changes from a CLI.

Database DevOps makes everyone happier.

Share your story before Mar 20 and good luck.