This document discusses techniques for automating the setup of developer sandboxes using metadata tools and source control. It emphasizes creating repeatable processes for deploying configuration versions, loading test data sets, and running unit tests. This allows for environment parity, more agility in development, and continuity across environments. Specific tools and targets discussed include the Force.com Migration Tool, source control systems like Git, and sample Ant build scripts for deploying changes, purging data, and executing tests. Roadmap items are also presented for improving deployment speed and exposing more metadata through the API.

1. Advanced Application Lifecycle Management
Tear Down, Rebuild, Reconfigure, Rinse and Repeat: How to Get the Most out
of your Developer Sandboxes
John Vogt, Senior Product Manager, Salesforce.com
Eric Wilcox, Senior Developer/Architect, Financial Force

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.

3. Eric Wilcox
Senior Developer/Architect
roc.wilcox@gmail.com

4. John Vogt
Senior Product Manager
Force.com Sandbox

5. Let Us Get To Know You

6. Goals for This Session
• Techniques for Automating the Setup
of your Sandbox
• Value your Developer Sandboxes
• Value repeatable Metadata API Tasks
• Value Test Data Sets

7. Lets Get Started!

8. Force.com Development & Customization Tasks
• Individual Develop & Unit Test
• Individual QA
• Team QA
• UAT
• Staging
• Scalability Testing

9. What is the best product for these Use Cases?
Product Type Description Use Cases
Full Full copy of configuration and production data Staging,
Storage limitation based on that of production org Scalability Testing,
29 Day Refresh Interval Training,
UAT
Configuration Only Full copy of configuration only (no data copied) UAT,
~ 250,000 Records at 500MB storage limit for data Code Integration & QA
Daily Refresh Interval
Developer Full copy of configuration only (no data copied) Development & Unit
Testing,
~5,000 Records at 10MB storage limit for data
QA
Daily Refresh Interval

10. Agile Sandbox Development

11. The Pillars of Agile Sandbox Success
• Use Metadata Tools
• Use Source Control
• Create Test Data Sets

12. Why are these Pillars Important?
• Environment set up continuity
• Effective deployment practices
• Environment parity
• More agility

13. Metadata Tools
Tool Description Use Cases
Force.com Migration • Full Metadata API Support • Environment Tear Down
Tool
• Repeatable Scripts • Configuration Deployment
(Ant Tool)
• Automation • Execute Unit Tests
API (WSDLs) • SOAP Access • Create Test Data
Enterprise
• Programmatic Interface • Configure Application Data
Partner
(custom settings, users, etc)
Metadata • Ant Integration

14. Simple Playbook

15. So, I need to develop and unit test – what do I need?
• Isolated workspace for a developer
• The ability to load a specific version
of configuration
• Access and ability to load test data
sets
• The ability to make and save my
configuration changes

16. What is needed in each QA environment?
• Isolated workspace for a for the QE
• The ability to load a specific version
of configuration
• Access and ability to load test data
sets
• Ability to test, tear down, and test
again

17. Repeatable Ant Targets
• Create and/or Tear Down Environment
• Load/Deploy Configuration Version
• Load Test Data and Custom Settings
• Run Tests

18. Create and/or Tear Down
Environment

19. Teardown – How To Dynamically Clean An Org
1 Ant Retrieve
Clean
2 Std Obj Layouts
Target Org
3 Build Package
4 Deploy Layouts
5 Build Destructive Changes
6 Deploy

20. • Remove Extraneous Items
• Renamed by Developers
• Triggers/Validation rules added
to for testing
• Downgrade to Earlier Version
• Urgent Bug Fixes
• Rollback a code change
• Continuity/Consistency

21. Deploy Configuration Version

22. • Continuity/Consistency
• Version Control
• Version Build Tools

23. Load Test Data and Custom
Settings

24. • Create Test Data Sets
• Use Existing Skills (Apex)
• Create Robust Data
• Continuity/Consistency
• Agility

25. Run Unit Tests

26. • Developers Run Relevant Tests
• Regularly Run All Tests
• Review Output/Monitor for Errors
• Continuity/Consistency
• Agility

27. Quick Review

28. Notes & Information

29. Source Control Systems:
• CVS, SVN, GIT, VSS
Session Content
• URL:
• https://github.com/financialforcedev/df12-deployment-tools
• Includes:
• readme for integration tips and info
• Ant “build.xml” with demo’d targets
• Sample Salesforce App w/ dummy classes, trigger, etc
• Java Samples for Anonymous Execution and Purge on Delete

30. Roadmap

31. Faster Deploys to Production PILOT
Only Run Specified Tests
Must Cover Code Changes
75% Coverage Per Class
Force.com Migration Tool

32. Reduced Sandbox Set Up Time PILOT
Copy the Objects You Need
Omit the Objects You Don’t
Obfuscate Sensitive Data
Subset of Records
Shorter Time To Use

33. More Metadata Exposed SPRING ‘13
Approvals Entitlement Processes
Business Hours Lead Assignment Rules
Case Assignment Rules Milestones
Case Escalation Rules Opportunity Teams
Case Team Roles Scheduled Apex Jobs
Contract Line Items Search Layouts Standard Objects
Communities Sharing Model

34. John Vogt Eric Wilcox
Senior Product Manager Financial Force
Salesforce.com