Cloud Journey- Post Sales Series

1. Development Best Practice's
James Burns
Senior Director and Solution Architect, Customer Success
Office of CTO
jburns@salesforce.com

2. Forward-Looking Statements
​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 any litigation, risks associated with completed
and any 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-K for the most recent fiscal year and in our quarterly
report on Form 10-Q for the most recent fiscal quarter. These 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. Key Elements of a Salesforce Governance Framework
​Center of Excellence (CoE)
The process of managing governance.
​Change Management
The process of managing the overall program or project
lifecycle — from collecting business requirements to
moving code from development through production.
​Org Strategy
The design and structure of the foundational “orgs” or
areas where the customer’s Salesforce applications will
reside and run.
​Technical Governance
The guiding principles for effectively developing the
technical aspects of Salesforce.
Center of
Excellence
Change
Management
Org Strategy Technical
Governance

4. The Software Development Lifecycle: Salesforce Stages
Test
Ideas
Maintenance
Implement
Design

5. Software Development Lifecycle

6. The Traditional Development Process
​Traditional systems often create a traditional cadence
Source Control
System
Developer Community
Production Systems
Functional Testing
Integration Testing
Business Testing

7. Salesforce Way
Backlog
Release
Management
Development Process
Ideas
Business
Backlog
Sprint
Developers
• Code or
Configure
• Unit Test
• Migration Scripts
Testing
User
Acceptance
Testing
Production
Environmental Management
Agile Methodology
Break-Fix

8. Recommended Development Methodology: Agile
Daily
2–4
Weeks
No Duration Changes
Input From
Customer
Sprint
Planning
Meeting
TrainingArchitectSprint
Backlog
Business
Backlog
Review

9. Environmental Management
​Allow multiple teams to develop new capabilities

10. What Can You Change in Production?
Customers often ask, "What can we change directly into production?”
Generally, “nothing” is the answer, but there are exceptions.
Examples of tasks that can happen in production:
• Administration tasks such as single sign-on (SSO) certifications
• Minimal risk administration changes in production:
• Templates: email, dashboards, reports
• User management
• Knowledge management
• Other changes (these should follow a decision tree)
Note: Sync any changes made in production with a source control system.

11. Decision Tree
Requirement
Does it affect
another
application?
Does it affect
another process?
Does it involve a
data change?
Does it involve
a UI change?
Implement with a test
plan and update the
source control.
Yes
No
Yes
No
Yes
No
Yes
No
IMPACT Analysis
No
Yes
Add to the backlog
and roadmap.
Make sure all
Stakeholder are
considered
Yes

12. Release Strategy: Options
Few
Major
Releases
Salesforce
Releases
Break-Fix
Minor
Releases
Enhancements Many
SimpleEffortLevelDifficult

13. Sample Environment Architecture: Major (1)
1. Developer: In this sandbox, multiple people work together
on the same use case. In this example, they share the same
developer sandbox. Often, a mixed team of experienced and
novice developers work together, which fosters a transfer of
skills. The experienced developers can help with the creation
of ANT scripts.
2. Developer: In this case, there is a one-to-one ratio between
developers and sandboxes.
3. Developer Initial QA: This sandbox is where the QA team
has started to build their QA test scripts; this work can be
started within a Developer sandbox.
4. Developer Pro QA: When all the user stories for a sprint are
completed, all the code and configuration merge together so
the QA team can ramp up their testing. In this case, the
volume of test data is normally greater, so a Developer Pro
sandbox is
the best selection.
Developer
Developer
Developer
Initial QA
Developer
Pro QA
Full
Break-Fix
Full
Training
Full Performance
Testing UAT
Partial Integration
Testing
9
1
2
38
4
56
7
Production
Source Control

14. Sample Environment Architecture: Major (2)
5. Partial Integration Testing: Most Salesforce solutions
involve integration to other systems; to perform this testing,
sample of production data is normally required. We
recommend a Partial Data sandbox.
6. Full Performance Testing UAT: To complete UAT, you need
a complete copy of production data.
7. Full Training: Before you update the production system, you
need to offer training to users: a Full sandbox is the best
experience for this scenario.
8. Full Break-Fix: As customers begin using Salesforce for
business-critical systems, you need to test all changes in
production. Since human errors occur, a break-fix process
(which is independent of a release roadmap) is required. To
support this process, a you need a Full sandbox that is
independent of the release roadmap.
9. Production: This is a current production instance.
Developer
Developer
Developer
Initial QA
Developer
Pro QA
Full
Break-Fix
Full
Training
Full Performance
Testing UAT
Partial Integration
Testing
9
1
2
38
4
56
7
Production
Source Control

15. Development Best Practices
​Good development starts with design

16. Development
​The Salesforce platform is based on the Model-View-Controller (MVC) architectural pattern:
Controller
Application logic
Model
Objects (standard,
custom, and external)
View
User interface
(web client and the
Salesforce1 Mobile App)

17. A Solid Architecture Starts With These Design Principles
• Build a data model.
• Put configuration first.
• Ensure the 80–20 rule.
• Create personas.
• Keep it simple.
Remember: The overall process is to design, develop (configuration and code), and test.

18. Design Challenge and Considerations
Challenge Your team lacks understanding of the scope of the configuration capabilities.
Considerations
• The developers for your project:
• What is their background?
• Do they jump into code?
• What is their mindset for writing code?
• Code review: Determine if it can be replaced by configuration.
• Design: Ensure sufficient time for designing the system during sprint planning.
• The 80–20 rule: Go fast and iterate.
• Over configuration: Use a small amount of code (sometimes it improves the overall maintainability of the system).
• Available components (within AppExchange): Use the “buy or build” strategy.
• Strategic planning: Use a Salesforce roadmap to benefit your project.
• Long-term maintainability: Make the design cost effective.
Visual Development – When to Click Instead of Write Code

19. Configuration or Coding?
Configuration Coding Challenges
• Build a data model.
• User interface
• Reporting
• Business logic:
• Formulas
• Validation rules
• Workflows
Advantages
• Scalable
• Maintainable
• Fast
• You don’t need to be a programmer.
Disadvantages
• Fixed UI
• Can get complex.
• Advanced business logic
• Testing
• Triggers
• Controllers
• Classes
• Custom UI
Advantages
• Flexibility
• Strong versioning
• Can be reused.
Disadvantages
• Can get complex.
• Technical debt
• Testing
• Skill sets:
• Business analysts and professionals
• Programmers
• A custom UI may require Apex code.
• Time to market
• Declarative testing
• Complex systems – declarative
• Security
• Large data volumes
Best Practices Tips:
• Push declarative testing to the limit.
• Remember: “80 percent is good enough.”

20. Testing Strategy
​Learn how to set up effective testing

21. The Testing Cycle
Development
User Acceptance
Testing
Production
Release
Manager
Perform
Unit Tests
Evaluate
Outcomes
Refactor or
Push to QA
Write Code
Quality Assurance
Functional
Test
Regression Test
Automated
Smoke Test
End-to-End
Performance
TestApproved
Failed

22. What’s Required?
Component
or System-
Level Testing
User
Acceptance
End-to-End Environments
Testing
Performance
Tools

23. The Salesforce Testing Strategy
Component
Functional
Client
Integration and
Performance
End-to-End
Regression
Code and
Configuration
When Should
I Do It
Tools Types
Testing
Why It’s
Important
Roles and
Responsibilities
Types

24. Release Management
​Let’s look at how software is managed between environments

25. The Effects of Poor Release Management
​The consequences of a poorly managed software release or environment include:
• Too many sandboxes.
• Lack of ownership.
• No clear path to production (change set,
ANT, managed package, or manual).
• Low-quality coding and testing.
• Conflicting release calendars.
• Frequent conflicts with code and configuration.
• Unclear system integration maps.
• No planned refresh schedule.
• Developers, testers, and release
engineers under constant stress.
• Unsuccessful deployments.
• Changes made directly in production.
• Overall low quality and adoption.

26. Our Recommendations
People Tooling Benefits
• A release manager who is
independent of development
and QA should perform
the release.
• The Business owner should
approve any changes in the
production environment.
• Remember: Separation
of duties (as recommended
by ITIL).
• For most projects — except for
very small ones — you’ll need
additional software tools to
manage source control and
automated builds.
• These tools are generally
inexpensive or free
to purchase.
• However, they will need to be
hosted either on an on-site
server or on a cloud service.
• Faster, more reliable
deployments
• More innovation in less time
• Higher user adoption
• Better ROI
• Less IT operations risk

27. The Path Forward
​How to achieve your long-term goal
What can you achieve with better software release and environment management?
• Clearly define your release environments.
• Define and enforce duties.
• Assign owners to sandboxes and deployments.
• Automate testing and deployment.
• Unify and publish a release calendar.
• Introduce the concept of release waves.
• Reduce the number of off-cycle releases.
• Communicate everything.
• Improve quality and enhance adoption.

28. Metadata API
​Metadata API is designed to retrieve, deploy, create, update, and delete customization
information for your organization
XML
Standard Objects
XML
Custom Objects
XML
Report
XML
Workflow Rules
XML
Apex Classes
XML
Apex Trigger
XML
Visualforce Pages
METADATA API
(Web Service Description Language)
Source Code
Repository

29. Code Migration: Best Practices
At the start of the day, perform these tasks:
• Refresh your sandbox and get the source control system to push the
metadata to the new org.
• Remember: By refreshing the sandbox, you will lose all the original
code and configuration.
• Ensure that migration scripts are correct by testing prior to moving
to a sandbox.
• Verify that:
• Your previous day’s work has been presented.
• Your enhancements have not been broken by other developers’
enhancements (run your test scripts again).
Keep in mind the following:
• An automated script will
not impact productivity,
but it will enhance quality.
• This process is not only
testing the enhancements
— it’s also testing the
migration process.

30. Tool Best For Limitations
Change Sets • Sandbox to production migrations
• Change management without source control
• Auditing previously deployed changes
• Enforcing code migration paths
• Deploying the same components to multiple orgs
• Small implementation
• You can only move metadata between a production
or and its sandboxes.
• You can't delete components.
• There is no support for source control.
Eclipse IDE • Project-based development
• Deployment to any org
• Synchronizing changes
• Some setup is required.
• It’s not always upgraded at the same time as other
Salesforce products.
• It has repeatable deployments that require re-selecting
components, which can be time consuming and can
introduce errors.
Force.com Ant
Migration Toolkit
• Scripted and scheduled deployments
• Repetitive tasks using the same set of components
• It requires a more developer-oriented skill set (familiarity
with Ant, scripting tools, and CLI).
• It requires storing a username and password on a disk,
which may be against your security policies.
Summary of Migration Tools

31. Tool Best For Limitations
Force.com Workbench • Ad hoc queries
• Metadata describes
• Lightweight data loads
• It’s not an officially supported product.
• It does not have project management features.
Force.com Command-
Line Interface (CLI)
• Passwords prohibited from being stored on disk due
to security polices
• Required interactive login
• Scripting and automated tasks
Logging in may be difficult behind a firewall.
Unmanaged Packages • One-time setup of a development environment
• A starting point configuration that is customizable
You can't make further changes to packaged
components using subsequent packages.
Managed Packages • Commercial applications
• You want to add to multiple orgs,
possibly non-related orgs
• Access to code is limited or hidden.
• Unique namespace can be bothersome or a blocker.
• Difficult to modify or delete components.
Summary of Migration Tools

32. Source Control: Best Practices
Commit early and often:
Commits should be small and should work together.
Push code to the system at least daily.
Accompany every commit with a short description
of what is being committed.
Code should be assigned to one of at least
four branches:
Trunk, development, integration, and break-fix.
Additional R&D branches can be created simply
for trying ideas.
Make sure releases to QA and production are
tagged centrally.
• Tag release 1.0 as Production_Release_1.0.
• Tags are never modified after they are created.
Don’t push code that does not build or pass
unit tests.
Do push code that builds, but may not be
perfect yet.

33. Release Manager: Best Practices (1)
Avoid making changes directly into production.
Refresh all sandboxes as soon as possible after
a release has been pushed to production.
Refresh can take time if you have large
data volumes (LDV).
Ensure that all migrations are automated.
Ensure all migration scripts are tested.
Avoid use of change sets.
Script unsupported metadata (if you
are using) to the automated process.
Complete regression testing before coding is
pushed to production.
Ensure that developers create a unit test for all
code and configuration.
Aim for 95 percent code coverage of Apex code.
Consider using the Quick Deploy feature to find
issues quicker.

34. Release Manager: Best Practices (2)
Make sure you have a well-documented
release roadmap.
Avoid any delay in the planned release date.
• Capability is failing to meet the definition
of done.
• Capability is cut and added to the backlog.
Ensure that applications within the same
org follow the defined release schedule.
Plan a regression test cycle on a pre-release
sandbox before a Salesforce release.
Ensure that business users complete UAT and use
the system as they would in their daily work.
The users should not follow a predefined script.
Put a comprehensive communication plan in
place for the release.
Develop a training plan and create content
before the release.
Note: A release manager who is independent of any Scrum team should manage the release process.

35. Release Manager: Roles and Responsibilities
Accountable Responsibilities Interfaces With
• Manage all aspects of the
end-to-end release process.
• Sign off the release
for implementation.
• Coordinate Scrum, UAT,
and third-party teams.
• Ensure teams follow the
company's established
policies and procedures.
• Follow the service release and
deployment policy and planning.
• Ensure all data migration has
been completed successfully.
• Document outstanding known
errors and workarounds.
• Release documentation,
communications, and training.
• Implement a source
control system.
• Provide a release roadmap.
• Conduct service roll-out planning.
• Manage reports on release
progress and service-level
agreements (SLAs).
• Ensure release acceptance,
including Business sign-off of UAT.
• Security management
• Test management
• Adoption management
• Training management
• Communication management
• Support management

36. Release Management
Source
Control
Production
Environment
Development
Testing
Integration
Testing
User
Acceptance
Testing
Apache Ant
Developer
Edition
Developer
Edition
Developer
Edition
Developer
Pro
Partial
Data
Full
Developer
Developer
Developer
Update Production

37. Summary
​Agile
​Environmental Management
​Development
​Testing
​Release Management

38. thank y u