1. No Surprises Development and
Environment Management
Stewart Bryson, Rittman Mead
& Kellyn Pot’Vin, Enkitec

2. 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.

3. Deployment Strategies in the Workplace
 Formal Strategy?
 Agile?
 Waterfall?
 Other?

4. Database World View
 DBA
The GULF In between
 Developer

5. 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

6. 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.

7. 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?

8. 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?

9. What do We Need to Be Successful?
 What do we want?
 What do we need?

10. 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

11. 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

12. 2. Restrictive security prevents
comparing schemas across
Environments ris o ns be twe e n
Re s tric ts c o m p a
d e ve lo p m e nt, te s t, QAa nd p ro d uc 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

13. 3. They don't practice deployments in
the environments they have
a) 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

14. 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?

15. 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.

16. 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!

17. 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.

18. 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.

19. 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.

20. 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!