Integrate CMS Content Into Lightning Communities with CMS Connect
7 Principles for Successful Release Management in Large Enterprises
1. Release Management for Large
Enterprises
7 5 Principles of Highly Successful Releases
Rajan Chowhan, salesforce.com, Technical Solution Architect
@rajanchowhan
Srini Konakalla, salesforce.com, Director-Strategic Services
@srinikona
2. Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if
any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-
looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of
product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of
management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments
and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our
service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth,
interruptions or delays in our Web hosting, breach of our security measures, the outcome of intellectual property and other litigation, risks associated
with possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain,
and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling
non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the
financial results of salesforce.com, Inc. is included in our annual report on Form 10-Q for the most recent fiscal quarter ended July 31, 2012. This
documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may
not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently
available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
8. Reduce Risk
“This just does not work
for me” – Sales Executive
“I just thought it would look
a little different than this” –
http://blogs-images.forbes.com/glennllopis/files/2011/04/risk.jpg
Operations Manager
9. Increase Stability
“That change that Srini made has stopped people entering orders!”
“It tested fine in the UAT environment, so why is
production down!”
“Rajan fixed the bug in the case page rendering but introduced 2
others!”
10. All While Improving Throughput!
Backlog
Steve is the…..
http://www.picarro.com
11. How good is your release process?
You would let Dr. Evil (and mini me!) mess
with your org, knowing your tests will pick up No regression
bugs… ??
Zero bugs
100% user satisfaction
Your backlog is always empty
(“the business” users just cannot fill
it!).
Rollback – what’s that?!?
13. Principle #1
Plan for
LDV
Define an Environment Strategy upfront
Hint: Ad-hoc sandbox proliferation is not good.
14. Example: Environment Strategy for Small orgs
Development Test Integration
Dev
Config Full Copy Prod
Dev
1 Full copy
sandbox
Types of Sandboxes
Development
Configuration Only
Full Copy
15. Example: Environment Strategy for Larger orgs
Dev 1
Test Cycle 2
Quarterly [External
Test Cycle 1
Release #1 Integrations]
Dev n
Load Test Stage Production Innovation
Dev 1
Quarterly Test Cycle 2
Release #2 Test Cycle 1 [External
Integrations]
Dev n
Support
Dev 1
Monthly Test
Release #1
Dev n
Dev 1 10 Full
Monthly copy
Test sandboxes
Release #2
Dev n
16. Principle #2
Bring the pain forward
Integrate code early in the development process
17. The Tools
Force.com
Metadata API Sandbox
Easy Access to Code Instantly Set Up
and Schema Dev Environments
Eclipse
Force.com IDE Change
Sets
Everything You
Need to Build Easy Tool for Admins
Apps to Migrate Changes
18. Continuous Integration
Continuous Integration (CI) is a technique used to quickly identify the many
issues that arise when integrating code. Code repositories and build servers are
core components.
20. Principle #3
Build Quality In
100% Code Coverage is not enough!
William Deming: “Cease dependence on mass inspection
to achieve quality. Improve the process and build quality
into the product in the first place”
21. Build Quality - Best Practice
Diagram invented by Brian Marick
23. Principle #4
Measure, measure, measure!
Impact of change
24. Measure, Measure, Measure
Measurement How?
How much change is happening? Source code deltas
How often is it happening? Release cycles
What types of change? Triggers, pages, fields, workflows etc.,
What are the results of those # of bugs introduced, severity of bugs,
changes? downtime (in minutes, in dollars),
26. Principle #5
Lather, Rinse and Repeat
Automate Deployment
27. Summary
Define an environment strategy upfront. Plan for LDV.
Bring the pain forward. Integrate code early.
Build quality in. 100% code coverage is NOT enough.
Measure. Measure. Measure.
Lather, Rinse and Repeat. Automate Deployments.