No Surprises Development and Environment Management

Stewart Bryson, Rittman Mead& Kellyn Pot’Vin, Enkitec

About This Session

Other programming disciplines have taken advantage of collaborative development principles to achieve quality code faster, such as:

Agile methods

rapid feedback

What techniques are available to enable higher levels of visibility and traceability when developing database code and schema objects.

Deployment Strategies in the Workplace

Formal Strategy?

Agile?

Waterfall?

Other?

Database World View

DBA

The GULF In between

Developer

Challenges

The ability to constantly build and deploy code into identical environments is one of the core essentials to ensuring successful releases.

There is incredible value in constant environmental comparisons which can reduce potential deployment problems between: Developer Database Copies

Central Development Databases

Integration Environments

Reporting Environments

Production

Secondary Objectives

Know more about Oracle's built-in capabilities for tracking database changes.

Learn how different tools can can support Oracle deployments to facilitate development, deployment, and quality peer reviews.

Learn about how to leverage compare tools to reduce potential code movement and deployment issues.

Performing a Release, Can you answer:

1. Exactly what is being changed in the database?

2. If they're using scripts to make the changes, have the scripts been run against a copy of the production schema anywhere before attempting them in production?

3. How long will the scripts take to run?

4. Are all of the scripts documented?

5. Is there a run-book /install guide that lists each script?

So Much Can Change….

5. Which scripts can be "pre-deployed" or "dark-launched"? (i.e. won't affect a running system.)

6. Which scripts require an outage?

7. Which scripts can be run post-outage?

8. If we need to abort, what is the minimum set of things we need to revert back to pre-deployment versions?

What do We Need to Be Successful?

What do we want?

What do we need?

To Ensure You are able to Answer These Question, it will Require: Following Environments:

2 in Development

2 in Integration

2 in QA

1 in Production Reporting

1 in Production

1. They don't have a production copy.

a) Skills/Resource to Create a Production Copy

b) Lack Disk Space to Create Production Copy

c) Inability/Lack Resources to Utilize Snap Mirrors/Re-Silvering

d) Logical Data Guard

e) Golden gate

f) Delphix

2. Restrictive security prevents comparing schemas across EnvironmentsRe s tric ts c o m p a ris o ns be twe e n d e ve lo p m e nt, te s t, QA a nd p ro duc tio n. .

a) Ask why, demand a logical answer.

b) Find a way around it, there are tools to extract baselines

c) Write a sql script to dump details to a .txt file and just diff them

d) Find a process to constantly verify that the structure in Production is what you expect it to be.

3. They don't practice deployments in the environments they havea) From Development to Integration or from schema to schema

b) From Integration to QA

Does QA file bugs when the installation scripts fail?

c) From QA to Production Reporting

4. They think that small structural differences "don't matter"a) The index names are different, how could this impact a release?

b) The columns are in a different order, what is the big deal?

c) Storage clauses are assumed, it’s an issue?

d) They run RAC and DG in production, but nowhere else, it matters?

Internal Database Tips

DDL Auditing turned on, considered default in environments.

It is FREE, has almost no overhead and grants the administrator a list of structural changes occurring as the changes happen.

All change scripts should be generated at the object level, (SQL Developer is already equipped to handle this.)

Take advantage of schema compare tools repeatedly to “weed out” and eliminate any structural differences prior to deployments.

Test, test and re-test deployment scripts, preference is always against a production copy.

Tips for Simplifying Environments

Tablespace names the same across ALL environments.

Storage clauses all AUTO ALLOCATE

Column ordering the same.

Index checks to verify all the same across all environments.

Remove ALL DIFFERENCES that can impact simplicity when duplicating.

Consider differences to be bugs that require fixing.

If production is RAC, all environments that support it, (dev, test, QA) should also be RAC!

Cost Effectiveness

Price of implementation vs. the cost of failure.

Track accumulated savings in shortened outage windows.

Consider more frequent deployments, which can be performed quickly and confidently.

Tools that Can Assist You

SQL Developer, (Oracle)

Pl/SQL Developer, (All Around Automation)

TOAD Software, (Quest Software)

Redgate Deployment Suite for Oracle

DB Artisan, (Embarcadaro)

Object Level Scripting

Schema Comparison

Plug-in for many version control software pkgs.

Oracle Deployment Tools

Oracle Technology Network Website has documentation for a plug-in.

http://www.oracle.com/technology/documentation/agile.html

Weblogic applications possess the Weblogic Deployment tool.

Oracle Warehouse Builder

EM12c- Use Middleware as a service as to rapidly deploy J2EE

applications.

Auto deploy options for patching, upgrading, etc of Oracle internal code.

Production Deployments Best Practice Review A practiced task before the actual event, at least 2-3

occurrences before going production.

All issues/bugs should be ironed out before ever going to production so…

The Production Deployment is then a NON- EVENT!