Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Enforcing Corporate Standards in a DevOps World

DZone's Guide to

Enforcing Corporate Standards in a DevOps World

· DevOps Zone
Free Resource

Best practices for getting to continuous deployment faster and with dramatic results in reduced outage minutes, development costs, and QA testing cycles. Brought to you by Rainforest QA.

We announced the Datical DB Rules Engine  at a conference last week. And I was so pleased with the response to how Datical DB automatically enforces your Corporate, Technical, and Regulatory database standards.

We all have standards for our database changes and I put them in three buckets:

  • Process
  • Sanity
  • Safety

Now the first bucket is your corporate or department rules. Things like, “always include your JIRA ticket,” or “Only Tina and Steve are allowed to update Stored Procedures.” The second bucket is for things that anyone should know. This includes “don’t set a default value when you add a column to an existing table” or “make sure indices exist on columns you use in a foreign key”.

The last one is the one that keeps DBA’s up at night: SAFETY.

See, DBA’s don’t just administer the database; they protect the data. And data is the most important artifact from the application. Platforms come into favor and then disappear. (Looking at you, Cold Fusion!) But, the data remains as those applications are refactored, and re-architected.

That’s why DBAs don’t like taking changes directly from development. They’ve been burned by some Developer who thought it was cool to DROP a column and replace it with two others. Of course, the DROP was before the select/insert to move the data. Whoops! Meanwhile the DBA is restoring from tape, hoping that they don’t have to expand the maintenance window. Of course, this is all happening while the developer who submitted the change is snoozing peacefully in bed, oblivious to the turmoil he caused.

Well, we’ve got your back, DBA! With Datical DB Rules Engine, you can make certain Dev never uses DROP. Period. You can also lock down GRANTs. Heck, you can even make sure no one slips “TRUNCATE” into their Stored Procedures, too.

If you can imagine it, Datical DB Rules Engine can enforce it. You want to make sure that your Sequences in Data Center A are odd while the ones in Data Center B are even? No Problem. Seriously. ANYTHING you can imagine, we can enforce.

Now, imagine that enforcement being driven by your favorite DevOps orchestration product. Now, you can make certain Database changes don’t get out of QA unless they meet your corporate, technical, or regulatory standards.

Hopefully, what you’re imagining is more restful nights and less firefighting.  But, don’t take my word for it. Reach out to us here and take it for a test spin.

Or, if you think you’ve got a doozy of a standard, we’d love to hear about it at info@datical.com. We haven’t been stumped yet!

Discover how to optimize your DevOps workflows with our on-demand QA solution, brought to you in partnership with Rainforest QA.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}