Development Best Practice's

James BurnsSenior Director and Solution Architect, Customer SuccessOffice of CTOjburns@salesforce.com

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.

Key Elements of a Salesforce Governance FrameworkCenter of Excellence (CoE)The process of managing governance.

Change ManagementThe process of managing the overall program or project lifecycle — from collecting business requirements to moving code from development through production.

Org StrategyThe 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

The Software Development Lifecycle: Salesforce Stages

Test

Ideas

Maintenance

Implement

Design

Software Development Lifecycle

The Traditional Development ProcessTraditional systems often create a traditional cadence

Source Control System

Developer Community

Production Systems

Functional Testing

Integration Testing

Business Testing

Salesforce Way

BacklogRelease

ManagementDevelopment Process

IdeasBusiness Backlog

Sprint

Developers• Code or

Configure• Unit Test• Migration Scripts

Testing

UserAcceptance

Testing Production

Environmental Management

Agile Methodology

Break-Fix

Recommended Development Methodology: Agile

Daily

2–4 Weeks

No Duration Changes

Input From Customer

Sprint Planning Meeting

TrainingArchitectSprint Backlog

Business Backlog Review

Environmental ManagementAllow multiple teams to develop new capabilities

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.

Decision Tree

RequirementDoes 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

Release Strategy: Options

Few

Major Releases

Salesforce Releases

Break-Fix

Minor Releases

Enhancements Many

Sim

ple

Effo

rt L

evel

Dif

ficu

lt

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

DeveloperInitial QA

Developer Pro QA

FullBreak-Fix

FullTraining

Full Performance Testing UAT

Partial IntegrationTesting

91

2

38

4

56

7

Production

Source Control

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

DeveloperInitial QA

Developer Pro QA

FullBreak-Fix

FullTraining

Full Performance Testing UAT

Partial IntegrationTesting

91

2

38

4

56

7

Production

Source Control

Development Best PracticesGood development starts with design

Development The Salesforce platform is based on the Model-View-Controller (MVC) architectural pattern:

ControllerApplication logic

ModelObjects (standard,

custom, and external)

ViewUser interface

(web client and the Salesforce1 Mobile App)

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.

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

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

Testing StrategyLearn how to set up effective testing

The Testing CycleDevelopment

User Acceptance Testing

ProductionRelease

Manager

Perform Unit Tests

EvaluateOutcomes

Refactor or Push to QA

Write Code

Quality Assurance

Functional Test

Regression TestAutomated

Smoke Test

End-to-End Performance

TestApproved

Failed

What’s Required?

Component or System-

Level Testing

UserAcceptance

End-to-End Environments

Testing

Performance

Tools

The Salesforce Testing Strategy

Component

Functional

Client

Integration and Performance

End-to-End

RegressionCode andConfiguration

When ShouldI Do It

Tools Types

Testing

Why It’sImportant

Roles andResponsibilities

Types

Release ManagementLet’s look at how software is managed between environments

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.

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 reliabledeployments

• More innovation in less time

• Higher user adoption

• Better ROI

• Less IT operations risk

The Path ForwardHow 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.

Metadata APIMetadata API is designed to retrieve, deploy, create, update, and delete customization information for your organization

XMLStandard Objects

XMLCustom Objects

XMLReport

XMLWorkflow Rules

XMLApex Classes

XMLApex Trigger

XMLVisualforce Pages

METADATA API (Web Service Description Language)

Source Code Repository

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.

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 AntMigration 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

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

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

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.

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.

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-levelagreements (SLAs).

• Ensure release acceptance, including Business sign-off of UAT.

• Security management

• Test management

• Adoption management

• Training management

• Communication management

• Support management

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

Summary

Agile

Environmental Management

Development

Testing

Release Management

thank y u