Release and Enviromental Management

Release and Environment
Management
Align your Business and IT
James Burns
Senior Director and Solution Architect, Customer Success
jburns@salesforce.com

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

Software Development Lifecycle

Everything Works Together With Salesforce
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

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

Allow 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 Production
Understand 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
Requirement
Does it aﬀect
another
application?
Does it aﬀect
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 Release
Learn 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
SimpleEffortLevelDifficult

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.

Sandboxes
Get insights, learn the capabilities, and more

Sandbox Comparison
Developer 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.

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.
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
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.
present.
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
• Slower to copy.
• It may not be OK to give
Use Cases
Sandbox 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 Architecture
Examine 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
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

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

Release Management
Let’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 reliable
deployments
• More innovation in less time
• Higher user adoption
• Better ROI
• Less IT operations risk

Benefits
Effective 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 Practices
Understand what good migration looks like

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

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 Practices
Perform 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: Challenges
Consider 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 Deployments
These 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 Tooling
Learn how to implement change management

Deployment Options
Eclipse IDE Change SetsMigration Toolkit

Examples of ANT Files
build.xml
package.xml build.properties

Source Control
Who can benefit from this technology?

Benefits
Using 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.

Concepts
Trunk Tag
Release 1
Break-FixIntegrationProject 1Project 2
Release 1.1
Release 1.0.1
Release 1.0.2
UAT
Merge
Merge
Merge
Optional
Depends 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 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.

Summary
Discuss what we know now and the next steps.

Everything Works Together With Salesforce
Backlog
Release
Management
Development Process
Ideas
Business
Backlog
Sprint
Developers
• Code or
Configure
• Unit Test
• Migration Scripts
Testing
User
Acceptance
Testing
Production
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

Release and Enviromental Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Release and Enviromental Management

Similar to Release and Enviromental Management (20)

More from Salesforce Partners

More from Salesforce Partners (20)

Recently uploaded

Recently uploaded (20)

Release and Enviromental Management