managing change with a sensible sandbox architecture

18
Managing Change With A Sensible Sandbox Architecture Building a scalable process for testing and deploying innovation across your enterprise Alex Sutherland Enterprise Practice Lead & Technical Architect, CRM Science [email protected] @apexsutherland

Upload: alexander-sutherland

Post on 16-Apr-2017

277 views

Category:

Technology


1 download

TRANSCRIPT

Managing Change With A Sensible Sandbox ArchitectureBuilding a scalable process for testing and deploying innovation across your enterprise

Alex Sutherland Enterprise Practice Lead & Technical Architect, CRM Science

[email protected] @apexsutherland

Alex Sutherland

@apexsutherland

Enterprise Practice Lead CRM Science

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.

Overview

Why should I use sandboxes, and how many do I have available?

How should I allocate and structure my sandboxes?

Managing sandbox refresh cycles & major release cycles

Migrating changes between environments

Environment Hub and Single-Sign On

Additional Training Resources

Q & A

1

2

3

4

5

6

7

http://kidstoystalk.com/

What are sandboxes & why should I use them?

http://www.redargyle.com/blog/validation-rules-great-as-a-last-resort/

Why should I add time & effort with sandboxes?

“A stitch in time saves nine” - “A test in time saves nine(ty) hours of work”

Making changes in a sandbox and running a smart, targeted regression test for significant changes will often save you from disasters in production.

Sandboxes give you the ability to run many projects simultaneously without interfering with each other in the development process.

It gives you more freedom to explore the capabilities of the Salesforce platform, and be more innovative in the solutions you develop and implement.

What are sandboxes & why should I use them?

Complete configuration copies of your production environment

Depending on the type, may include some or all production data

• Developer - Configuration, Code, Users & Groups only

• Developer Pro - Configuration, Code, Users & Groups only (but with higher storage capacity)

• Partial Copy - All of the above, plus up to 10,000 records per object, up to 5GB total data

• Full Copy - (Almost) EVERYTHING from production

Distinct Salesforce environments with separate security controls & lifecycle

Enables admins & release managers to successfully implement a flexible change

management process

25 - Developer

($)

1 - Partial Copy

($)

10 - Developer

(N/A)

(N/A)

(N/A)

100 - Developer

5 - Developer Pro

1 - Partial Copy

1 - Full Copy

Unlimited Edition Enterprise Edition Professional Edition

(Change Sets not available in Professional Edition)

How many sandboxes do I have available?With the new Lightning Editions - a lot more!

Managing Sandbox Refresh CyclesUnderstanding (Minimum) Refresh Intervals

• Developer - 24 hours

• Developer Pro - 24 hours

• Partial Copy - 5 days

• Full Copy - 29 days

General best practice - release often & refresh often!

For complex release cycles, build a plan that staggers refreshes to minimize disruption

Use “downstream” Change Sets to keep sandboxes up to date in between refreshes

Salesforce Major Seasonal Release Previews

Look out for the email and blog post announcing the Seasonal Release Sandbox Preview

Window:

• https://www.salesforce.com/blog/2016/08/salesforce-winter-17-sandbox-preview-instructions.html

Look at your refresh cycle plan and extend or contract your refresh cycle plan to get the

sandboxes you want into the seasonal release preview

• Simple seasonal release preview analysis spreadsheet - http://goo.gl/n1oom0

How should I allocate and structure my sandboxes?

Just getting started

• 1 Partial Copy sandbox for User Acceptance Testing

• 1 Developer sandbox for configuration changes

Going deeper

• 1 Developer sandbox for Staging

• 1 Partial Copy sandbox for User Acceptance Testing

• 1 Developer sandbox for new development/configuration

• 1 Developer sandbox for production support/bug fixes

Going deep & wide

• Flexible enterprise development sandbox architecture and flow

Simple Sandbox Architecture

UAT

Support

ConfigAlex

Production

Staging

Developer/Dev ProSandbox Type Legend: Partial Copy

Enterprise Development Sandbox Architecture Production

UAT

Staging

Test/QA

Lightning

Lead DevDev 3Dev 2Dev 1

Config

Change Sets (in between refreshes)

Alex

Steelbrick

Developer/Dev ProSandbox Type Legend: Partial Copy Full Copy

Migrating Changes Between Environments

Manually

Change Sets

Packages

Metadata API/Tooling API Deployments

• Force.com IDE / MavensMate / Force.com Migration Tool

• Continuous Integration

Data Loader

Environment Hub & Single Sign-On

Enables admins to manage all Salesforce environments from a central hub

• Key for organizations with multiple production environments

• Enables generation of demo environments for short-term testing

Easily configure Salesforce identity provider Single Sign On

• Eliminate multiple password management for sandboxes

• Reduce risk of unauthorized access by deactivated users

• Link multiple production environments to one master

Change Management Resources

Trailhead Module - Change Management

https://trailhead.salesforce.com/en/module/app_deployment

Trailhead Module - Application Lifecycle Management

https://trailhead.salesforce.com/en/module/alm_deployment

An Introduction to Environments - Salesforce Developers

https://developer.salesforce.com/page/An_Introduction_to_Environments

Q & AStump the MVP!

Thank Y u