Release and Enviromental Management

Release and Environment ManagementAlign your Business and IT

James BurnsSenior Director and Solution Architect, Customer Success

[email protected]

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.

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

Software Development Lifecycle

Everything Works Together With Salesforce

BacklogRelease

ManagementDevelopment Process

IdeasBusiness Backlog

Sprint

Developers• Code or Configure

• Unit Test

• Migration Scripts

Testing

UserAcceptance

TestingProduction

Environmental Management

Agile Methodology

Break-Fix

Glossary

Code

Anything that makes up an application or set of enhancements. Salesforce uses this term in relation to migration to mean:

• Configuration.

• Apache Apex.

• Visualforce.

• Lightning components.

Developers

Anyone who makes metadata changes to a Salesforce org, including:

• Professional developers.

• Administrators.

• Business analysts.

Agenda• Environmental Management

• Changes Made in Production

• Roadmap Release

• Sandboxes Architecture

• Release Management

• Why Migration?

• Code Migration Best Practices

• Code Migration Tooling

• Source Control

• Summary

Environmental ManagementAllow multiple teams to develop new capabilities

What's Environmental Management?

Environmental management is the environment and its associated processes that allows multiple

teams to develop and test new business capabilities, fix production issues quickly without causing regression, and offer a system to train users on the new capabilities.

Reduce Operational Risk:

Minimize disruptions to your active org and your operations.

Raise Productivity:

• Allow your developers to spend less time working around constraints of your production org.

• Train users in a real-world environment so they transition seamlessly to your production org.

Increase Efficiency:

Seamlessly hand off tests and trials of new apps, new release features, and configuration changes to QA, and then the production org.

Higher User Satisfaction:

Experience more satisfied Salesforce users with better application quality, fewer disruptions, and training.

Increased Business Value:

• Provide better application quality, faster.

• Implement regular releases of business requirements.

Experience more stability for your active organization.

Shorten cycle times for testing and trials.

Set up a realistic training environment.

Create a separate environment for:

• Developing

• Testing

• Training

Provides a regular release cadence of capabilities.

Environmental Management Matters

Changes Made in ProductionUnderstand the effects of making changes in production

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

Roadmap ReleaseLearn the definition and best practices

Roadmaps: Benefits

The use of roadmaps helps:

• Allow consistent planning of these associated tasks:

• Communications

• End-user training

• Supported team training

• Prevent changes made directly into production.

• Ensure the correct sandbox architecture supports:

• The release roadmap plan

• The software development lifecycle

Best Practices:

All projects within the same org need to follow the release roadmap plan; there are no exceptions.

Note: Implement a regular Salesforce release cadence to meet the company's culture and business requirements.

Release Strategy: Options

Few

Major Releases

Salesforce Releases

Break-Fix

Minor Releases

Enhancements Many

Sim

ple

Effo

rt L

evel

Dif

ficu

lt

Release Strategy: Details

Break-Fix Minor Releases Major Releases Salesforce Releases

Bug fixes

Business configuration

Targeted monthly.

Has limited testing.

Simple configuration changes do not impact day-to-day business or require significant training.

There are no integrations.

Targeted quarterly.

Provides new initiatives.

Often requires significant testing and training.

Integration with a third-party system requires end-to-end enablement.

Many customers link upgrades with a major release.

Best Practices Tips:

• Remember key company dates.

• Document and communicate your release strategy.

• Every release should have a testing strategy: regression testing.

Roadmap: Sample

SandboxesGet insights, learn the capabilities, and more

Sandbox ComparisonDeveloper Developer Pro Partial Copy Full

Refresh Interval 1 day 1 day 5 days 29 days

Includes Setup Configuration? Yes Yes Yes Yes

Copies Data No No Yes Yes

Templates* and Sampling No and no No and no

Yes and yes (10,000 records

per object)

Yes and no (full data copy)

Size

• 200MB of data• 200MB file

• 1GB (approximately 500,000 records)

• 1GB file

• 5GB (approximately 2.5 million records)

• File storage depends on sample.

Match production for data and file.

* Templates can be used in cloned sandboxes.

Developer Developer Pro Partial Copy Full

Testing• Unit tests.

• Apex tests.

• Best used for feature testing.

• Important to load standard data for regression testing.

Best for production debugging for data subsets.

Best for production debugging.

Testing External Integrations (including performance)

Not a good fit.

• Use for special cases only.

• Use a sample or a subset of data when testing.

• Works well with external IDs.

• Frequently required.

• The external system expects full production data to be present.


• The external system expects full production data to be present and is required for performance testing.

Staging and User Acceptance Testing

Not a good fit.• Not recommended.

• Use sometimes with a production subset of data,

• Usually required.

• You’ll need to validate new apps against your production configuration and data.



Development Perfect. OK.

• Faster than a Full sandbox.

• Because of the data subset, it may not be OK to give developers access to data.

• Slower to copy.

• It may not be OK to give developers access to data.

Developer Developer Pro Partial Copy Full

Testing• Unit tests.

• Apex tests.

• Best used for feature testing.

• Important to load standard data for regression testing.

Best for production debugging for data subsets.

Best for production debugging.

Testing External Integrations (including performance)

Not a good fit.

• Use for special cases only.

• Use a sample or a subset of data when testing.

• Works well with external IDs.


• The external system expects full production data to be present.


• The external system expects full production data to be present and is required for performance testing.

Staging and User Acceptance Testing

Not a good fit.• Not recommended.

• Use sometimes with a production subset of data,





Development Perfect. OK.

• Faster than a Full sandbox.

• Because of the data subset, it may not be OK to give developers access to data.

• Slower to copy.

• It may not be OK to give developers access to data.

Use CasesSandbox tips and recommendations for your organization

Challenges (1)

Sandboxes do have a few challenges:

• During a sandbox copy or refresh, usernames are modified (and made unique).

• Customer Portal users aren’t copied to Developer and Developer Pro sandboxes.

• Sandboxes don’t send email notifications when storage limits are reached.

• The following features are disabled in sandboxes and can’t be enabled, which may impact testing:

• Case escalation and contract expiration warnings

• Content subscription summaries

• The Data Export Wizard

• The ability to create additional Salesforce sandboxes (You can clone them instead.)

• The ability to copy email service addresses

• Chatter data

• Object IDs

Challenges (2)

“The sandbox copy is taking forever.”

• The sandbox copy process uses shared customer resources.

• If multiple copy requests are made at once, customers may experience a slowdown in data flow.

• This usually occurs around the time of a sandbox preview cut-off date.

“Deployment failed due to Apex test coverage.”

• Over 75% of Apex test coverage is required for deployments.

• Production data often lacks variations compared to test data, which results in lower coverage.

“Our change set deployment failed due to a lack of dependent components.”

• This often occurs when components with dependencies are included in one chain.

• A change set does not automatically include the order of components and its dependencies.

• To avoid this error, admins should divide the chains into multiple sets and manually control the order.

Environmental ArchitectureExamine different architectures and design your own

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

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

Why Migration? Learn why it’s important.

Why Is Migration Important?

For Projects For Business Challenges

• Your projects are made up of multiple developers and work streams.

• Your organization has one copy and one version of everything. Data gets overwritten.

• Your Salesforce projects are becoming more complex.

• Large projects often suffer from not implementing tools and processes early enough.

• Large organizations need rigid change management processes and tighter control over system deployment.

• More and more, organizations need to have smaller releases at a higher frequency while minimizing risk.

• A poor deployment process results in:

• Reduced user adoption and ROI.

• Less-scalable applications.

• Salesforce has limited capabilities for release management.

Best Practices Tip: A good migration solution reduces operational risks.

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

BenefitsEffective software and release management can lead to:

• An improved ability to schedule sandbox refreshes.

• A reduced time to deployment as a result of higher quality of coding and less conflict.

• Valid regression testing.

• Better use of sandboxes as a resource.

• Clearly defined environments available for development and testing.

• Groundwork prepared for continuous integration.

• The ability to release on time.

• Improved quality of the end product.

• Reduced costs of the development process.

Migration: Best Practices

Scenarios: What You Want to Happen

• Multiple developers work on the same project.

• Multiple releases happen for the same project.

• Multiple applications get developed across business units.

Approaches: Make Scenarios Successful

• Ensure that you have the correct environmental management.

• Establish a program governance.

• Follow a Software Development Lifecycle (SDLC) process.

• Use and configure tools appropriately.

• Instill development best practices.

Code Migration Best PracticesUnderstand what good migration looks like

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

Unsupported Metadata Types• Account Teams

• Activity Button Overrides

• Analytic Settings

• Automated Case User Settings

• Auto-number on Customizable Standard Fields

• Campaign Influences

• Case Contact Roles

• Case Feed Layouts

• Case Team Roles

• Console Layouts

• Currency Exchange Rates

• Data Category Visibility Settings

• Delegated Administration

• Divisions

• Email Services

• Fiscal Year

• HTML Document and Attachment Settings

• Lead Settings

• Mail Merge Templates

• Mobile Administration

• Mobile Users and Devices

• Multiline layout fields for opportunity teams

• Offline Briefcase Configurations

• Opportunity Big Deal Alerts

• Opportunity Update Reminders

• Organization Wide Email Addresses

• Partner Management

• The following standard picklists: IdeaTheme.Categories, Order.Status, Question.Origin. (All other standard picklists are supported.)

• Predefined Case Teams

• Product Schedule Setup

• Public and Resource Calendars

• Quote Templates • Salesforce to Salesforce

• Standard fields that aren’t customizable, such as auto number fields or system fields

• Self-Service Portal Font and Colors

• Self-Service Portal Settings

• Self-Service Portal Users • Self-Service Public Solutions

• Self-Service Web-to-Case

• Site.com

• Social Account and Contact Settings

• SoftPhone Layout

• Solution Categories

• Solution Settings

• Tag Settings

• Territory Assignment Rules

• User Interface Settings (except calendar features, which are supported in Activities Settings)

• Web Links on Person Account Page Layouts

• Web-to-Lead

Manage Unsupported Metadata Types

Unsupported metadata types cannot be automated through an API as supported metadata types can. However, you can still automate unsupported data by:

• Defining the process to enable identification of the unsupported metadata components being changed by developers.

• Using web scripting tools like Selenium to automate changes from environment to environment.

The future of unsupported metadata:

• The list of unsupported metadata becomes smaller with every release.

• Newer capabilities are replacing unsupported metadata.

Org Metadata Comparison Tools

Why you want to compare an org’s metadata:

• To verify that the migration process has been successful.

• To help the developer to create the build manifest.

Specific Metadata Tools

Note: Most code migration tools also support the metadata compare capability.

GlimpserMetadata Tracker Org Compare Schema Lister

Migration: Testing and Tracking

Migrations require testing, and change can occur through the following:

• A Web user interface.

• Development tools.

• An API.

You can track changes through:

• Development and production, simultaneously.

• Metadata not available through an API.

• Audit trail.

Changes in production:

• Avoid making changes to Metadata that defines the application in production.

• You can still complete administrative tasks.

Code Migration: Best PracticesPerform these daily tasks:

• Record all configuration changes manually.

• Verify the setup audit trail within your developer sandbox.

• Record all Apex classes changes manually.

• Write your migration script to generate the metadata for your daily change.

• Write a unsupported migration script, if you’re using any.

• Run a metadata analysis tool to verify that nothing was missed.

• At the end of the day, push the metadata, unsupported scripts, and test scripts to a source control system.

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.

Migration: ChallengesConsider these challenges when migrating metadata:

Unsupported metadata types

Dependencies:

• Parent-child

• Referenced file

• Ordering

Mandatory fields

Sandbox refresh cycle:

• This may take time to refresh.

• Schedule a refresh in the project plan.

Salesforce release cycle:

• The production environment has two Sandbox PODS versions.

• Refresh Sandbox using the correct POD.

Changes made in production:

• Follow best practices.

• Changes maybe overwritten in production or vice versa.

• Changes will be lost.

Profiles and permission sets:

• Be careful if you’re making a lot of changes.

Changes That Impact DeploymentsThese practices, situations, or metadata API constraints could negatively impact deployment:

• API names

• Changes to field type

• Metadata dependencies

• Changing picklist values

• Changing active approval workflows

• Sharing rules

• Profile and permission sets

• Object IDs

• Users

Code Migration ToolingLearn how to implement change management

Deployment Options

Eclipse IDE Change SetsMigration Toolkit

Examples of ANT Filesbuild.xml

package.xml build.properties

Source ControlWho can benefit from this technology?

BenefitsUsing source control:

Promotes teamwork by giving everyone access to the latest code at all times.

Developers stay on top of changes by reading the commit log.

Facilitates code reviews.

Changes since the last review are easier to detect.

Allows different branches of code.

• Example branches: Master, generally available (GA), development, research and development (R&D), and more.

• You can easily switch branches when needed.

Allows new release versions and other important milestones to be tracked with tags.

Provides a backup of development efforts.

Protects your intellectual property (IP).

Provides a mechanism to store the state of applications at a particular time to meet regulation requirements.

ConceptsTrunk Tag

Release 1

Break-FixIntegrationProject 1Project 2

Release 1.1

Release 1.0.1

Release 1.0.2

UAT

Merge

Merge

Merge

OptionalDepends on Sandbox refresh

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.

SummaryDiscuss what we know now and the next steps.

Everything Works Together With Salesforce

BacklogRelease

ManagementDevelopment Process

IdeasBusiness Backlog

Sprint

Developers• Code or

Configure• Unit Test• Migration Scripts

Testing

UserAcceptance

Testing Production

Environmental Management

Agile Methodology

Break-Fix

Summary

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

thank y u