Change & Release Management

Tom NepaSuccess Manager

Agenda

§ Introductions

§ Change management

§ Release management

§ Process and governance

§ Environment management

§ Best practice and recommendations

§ Training and communication

§ Ongoing support

§ Next steps

§ Q & A

Change Management

High Level

§ How do you collect change requests?§ Where will you track and store requests?§ Who is responsible for managing requests?§ Who prioritizes?§ Who Schedules and assigns tasks?§ What does your development architecture look like?§ How do you roll up development releases?§ How do you handle QA/UAT issues?§ Approvals§ How will releases be communicated to users?§ When is training brought in the process?§ How does this tie into your project plan?

Change Management

§ Change Management is the process by which an organization identifies, prioritizes, assigns, executes and communicates change.

§ In a salesforce.com deployment this could result from– Organizational change

– Business process changes

– Addition or subtraction of processes

– Salesforce.com release of new versions

§ Different process for different change request– Big changes: Rolling new business lines

– Medium: Enhancements that affect specific line of business

– Simple: Fixes, Config change, Reports and templates

In the beginning, life was simple . . .

Hey, look how easy it was to add a custom field to this page layout! It took me 2 minutes and now all 20

of my users can access it!

We love how responsive Bob is to our requests!

As the platform matured, the possibilities expanded in both type and complexity.

Design an approval process for each country

where we do business

Add a custom button to the page

layouts used by our European

division

Add an Apex trigger to

implement our pricing algorithm

Install an AppExchange app to track expenses

Add a validation rule to enforce our

role-based discount matrix

Create a new custom app to manage events

I hope I don’t

mess up

Change control has become more important, especially in larger organizations.

Change requests must be

approved by the Change Control

Board.

All changes must be archived for

SOX compliance.

All changes must pass system test

before being deployed to production.

Dev Test Prod

Nobody messes up

on my watch.

We expect to use professional dev and version

control tools.

Why Change Management for Salesforce?§Why should change management be applied to Salesforce.com?

–You are dealing with an application that is in constant flux• Its fully customizable to your business• Its functionality improves and expands up to three times a year • Your users and go to market strategy are most likely changing and in turn your CRM system must evolve•Controlled change will allow you to focus on streamlined processes and maintaining consistency while remaining nimble and responsive•Limited application administration resources will require organization to obtain maximum efficiency •Top-down adoption is critical to success; a focus on bottom up adoption is also necessary for success

Change Management A process of continuous evolution

VisionStrategy

Objectives

Validate§ Audit Salesforce data§ Monitor performance metrics§ Use results to drive behavior

or process change within the organization where appropriate

Vision & Strategy § Establish program vision§ Define strategy to achieve§ Develop objectives to

ensure progress

Initiate/Plan§ Identify key

Salesforce capabilities required

§ Develop a roadmap to implement

§ Tie capabilities to program objectives

Operationalize§Build, configure,

and deploy application

§Manage organizational change (release mgmt, training, etc.)

§Drive adoption of new features

Continuously analyze your current state, collect user feedback and implement change when appropriate.

Who should be involved?§The users community

–Customer facing personnel, management and senior management should all have access to provide feedback and influence direction

§Key decision makers–The feedback and requests from the field must be triaged by an identified individual or group that has proper training, understanding of the system and business processes

–Enterprise Architects, Administrators etc.

§Change Control Committee or Steering Committee–A cross departmental group that has the overall business objectives and understanding of the overall vision. This group should meet regularly and the agenda should include select change control requests.

§Executive Sponsor–The leader of the Steering Committee should set priorities and ensure alignment with overall business goals.

Do all changes require “Release Management”? – No

Salesforce.com is designed for end users to make some configuration changes. Some of these changes can be made in production and shared when the testing is complete:

o Reports, Dashboards and List Views

o Adding a picklist value

o Adding a new user

o Group Membership

o Creating a territory

o Changing the label of a field

o Email Templates and Letterhead

o Creating a “message of the day”

These changes are still tested before being shared with end users. This is done through access controls!

Steps to Effective Change Management§ Get a strategy

– Define an execution strategy and try and keep it simple as possible

§ Collect input– Capture input from end users, cultivate interaction between change management group and end user

§ Get a sponsor – Having an engaged executive sponsor is key to establish Objectives, define Process and drive Adoption

§ Define scope and impact – Determine the level of effort, scope, and impact. Identify and align processes between functional areas

§ Prioritize – Get end user input to understand overall impact and prioritize user requirements

§ Implement and test – Define implementation, end user validation and deployment plan

§ Communicate and train users – Keep user community informed of changes so they are better prepared for adoption

§ Deploy – Define and adhere to a repeatable release management process

§ Follow up – Identify power users to follow-up on new release and define future enhancements

Release Management

5 Pillars of Release Management

1Deployment

Size & Cadence

2New Project Evaluation

3Environment

Strategy

4Training &

Communica-tion

5Ongoing Support Model

Evaluating New Projects

§ Define communication process for new projects

§ Projects requests are funneled through COE

§ All projects are entered into COE database (i.e. SFDC)

• Capture Business Unit Request

• High Level Requirements

• Alignment with overall program objectives

• Business Readiness

• Timeline for Launch

§ Review new project requests as part of COE meeting

§ Determine business priority and alignment with overall Program Roadmap

§ Define priorities in COE Project Database

§ Evaluate the short term and long term alignment with the goals

§ Evaluate alignment with ongoing or other pending projects

§ Evaluate how project will be supported (internal resources, external resources)

§ Evaluate administrative needs of the project and ongoing administration

§ COE makes recommendation to the business on the approach and timing of the project

§ Communicate pending projects to the Program Steering Committee

§ Communicate decision to the business sponsors

§ For projects moving forward the necessary individuals should be invited to participate in COE

New Project Submission

Project Prioritization

Project Decision

Long Term Evaluation/ Support

Release Management: Process FlowSF

DC

Use

rSF

DC

Adm

inC

hang

e C

ontr

ol B

oard

IT

Submits change request

Reviews request Approved?

Determinesrelease

timeframe

Analyzesrequest andtimeframe

IT required?

Configurefeature/

functionality

Sandbox Environment

Sandbox required?

Configurefeature/

functionality

Production Environment

Notifies CMMrequest

completedConducts Testing

(end-user & IT)

Moves changesto productionenvironment

Communicateschanges toend-users

User notified

Configuration Changes ManyFew

Simple

Difficult

Level of Effort

Source: Faulkner 2006

Immediate Releases

Minor (Monthly) Releases

Major Releases

§ Implement immediate changes§ Owned by individual sub-group§ Minimal impact to the production floor

§ Minor changes impacting two or more groups§ Thrice as often as a Major Release§ Minor impact to training and production

§ Major impact on production and integration§ Significant changes such as AppExchange development§ Aligned with platform releases§ Impact across more than one business unit

Prepare a Release Strategy – Multiple TypesDoes not dilute the value of force.com flexibility

Release Management: DefinitionsRelease Type Activities Examples Level of Effort

Immediate • Small changes, rapidly applied directly to PRD

• Min impact to users• Outside scope of

Change process

• Dashboards/Reports• Related lists• Data Loads• Territory Alignments

LOW• No training required • No integration• Implemented by BA

Minor (Monthly)

• Minor impact to users• Config, test and

deploy w/ minor impact to small # of users

• New Fields• New page layouts • New Objects• New Territory

structure

MEDIUM• < 1 day of training• < 1 week of config• IT involvement

Major (Quarterly)

• Significant change to business users

• UI change, data migration/integration

• Apex/VF Code

• AppExchange apps• Process-impacting

changes• Data migration• Integration changes• Impacts multiple BUs

HIGH• 1+ days training• 1+ weeks config• 1+ wks of integration

development• IT lead

Ø ReportsØ DashboardsØ List View ManagementØ Documentation ManagementØ User AdministrationØ Solution ManagementØ Communication TemplatesØ Email Templates

Business Responsibilities

Daily Changes

IT Responsibilities

Monthly Changes

Ø Minor Release: Simple configuration changes that do not impact day to day business or require training. As Required (Target Monthly)

Ø Major Release: New Initiatives and other changes that require training or testing. Dates determined by Steering Committee(Target Quarterly)

Division of Responsibilities

Release Time-line Estimate: Example

Release made to target environments incrementally as per

release management plan.

Important Processes to be implemented:

- Establish a release schedule • Add scheduled release milestones to project schedule to aid planning.• At least two releases per module: 1st release for module testing, 2nd release to test defect fixes.

- Change Request and Release interdependency• Change requests need to state intended release during impact analysis step (by Release Manager).• This release timing feeds in to regression test plans. (e.g. A CR for SFA module may be released after the SFA Module testing release is completed)• Reporting of CRs by release (and movement) needs to be more transparent as project progresses (consider using cases)

- Environment Freeze• Applies from CR freeze Day -8 until the specific environment is released (i.e. Release Deployed).• If there are no releases and release content is relatively simple, then the above time frames can be shorter.

Day -8Final cut-off for change requests to be submitted for inclusion in this release.

Decision on inclusion is at the Release Manager’s discretion (limited resource – project teams need plan ahead)

Days -8 to -5

• Apply final (approved) Change Requests to Dev Environment.

• Carry out tests to insure non-impact on cross-dependencies (e.g. Dashboards, new fields, etc).

• Testing involves Change Requestor.

Days 0

Release deployed to all target environments

Days 0Days -5Days -8

QA Mod Test

INT TRNUAT

Environment Freeze

...

Note: Days are suggestive

Appendix

Process &

Governance

Process Management

MethodologyDevelopment

& Release Management

EnvironmentManagement

Change Management &

Governance

Establish Process and Governance§ Development Process

– Develop Process for how various teams will collaborate

– Define a process to handle defects(bugs) and change requests• How do you collect requests?

– Incorporate Release Management process

– Define Version Control, Change Control, Backup processes

– Create an iterative development plan incorporating build dependencies and periodic testing

– Determine resources and their access levels to the various environments

§ Benefits– A well established process leads to a smoother development - scale

– Continuous build and sync may elongate initial development process, but has less downstream risks and impacts

Process and

Governance

Governance: Focus Areas

Development Processes§ Change Mgmt

§ Problem Mgmt

§ Environment Mgmt

§ Version Control

§ Code Migrations

§ Data Migrations

§ Coding Standards / Best Practices

§ Data Management Best Practices

Application Delivery / Support Model(s)

§ Procurement

§ Methodology (Agile, Waterfall, etc.)

§ Training

§ Skills

§ Resourcing Model (Onshore/Offshore)

§ Support

§ Governance

Support Request Process: Example

Above is a high-level support process.Detailed procedure for each process step needs to be developed in-house.

Key role§ Change Committee

– Who: A team of Functional, Technical, Management and Support personal

– Responsibility:

• Streamline change management and development process

• Prioritize change request and approve for development and deployment

• Conduct weekly (at times daily) meetings to evaluate change request and assess impact

• Identify implementation and migration path for change request

§ Support Manager– Who: A Person nominated to handle support request from user community.

– Responsibility: • Establish support levels and manage support team

• Handles support request / call and routes to appropriate support team

• Identifies defect / gap in functionality and creates change request

• Prioritizes and present to change committee for approval for development

• Can make change requests and raise defects to be made available in next release.

• Suggest development and release path based on user feedback

• Monitor Chatter and Idea boards and respond to user queries

Environment Management

Considerations

§ How many development environments do I need?§ How do I provision and manage the environment?§ How do I promote a collaborative development environment?§ How do I incorporate my organizational processes?§ What tools can I use to help me automate my processes?

Environments

Process and Governance

Development Practices

DevelopmentTools

7/15/14 30

Real-Time Sandbox Environments

Fully Replicated Development Environments

Support any IT Governance Strategy

Production-class Infrastructure

One Click Import/Refresh of Your Production Data

Refresh Anytime

Eliminate Risk in Deployment

Development Testing Training

Production

Configure, Develop, and Deploy using Sandbox

Instantly Set Up Dev Environments

Everything You Need to Build Apps

Easy to Collaborate on Projects

Eclipse Force.com IDE

Force.com Code Share

Force.com Sandbox

Easy Access to Codeand Schema

Metadata API

Force.com Migration Toolhttp://wiki.developerforce.com/index.php/Migration_Tool

Cloud Deploy

Easy Tool for Adminsto Migrate Changes

Sandbox Replicates Your Salesforce.com OrganizationProduction Salesforce.com Organization

Development

Sandbox: Create a separate on-demand application environment for…

TrainingTesting (QA)

Sandbox: Types, Features, UsesFeatures Best For…

Full § Copy of configuration /code

§ Copy of active data and files

§ Same storage limits as the production organization

§ Staging / UAT

§ Validating new apps against active configuration and data

§ Testing external integrations

§ Training

Configuration Only § Copy of configuration/code

§ No data copied

§ 500 MB data storage

§ Testing new features

§ Loading standard data for regression testing

§ Limited use for staging/UAT

Developer § Copy of configuration/code

§ No data copied

§ 10 MB data storage

§ Development

§ Testing new features

§ Apex tests

Environment DefinitionsSandbox Owner

(Suggested)Type Purpose

Development IT Config Only Constantly moving environment due to ongoing development.Development & unit testing.

Consolidated Development

IT Config Only Consolidated environment where development artefacts are consolidated , system tested and packaged for deployment downstream. Developers will have read only access and will be delegated administrators or selectively granted write access.

QA IT Config Only A controlled (non-moving) environment to test release candidates

Control IT Config Only Once a release passes the QA stage, it is released in to the control environment, from which the ‘physical’ releasing takes place as per the environment path. Historic snapshots of this environment will be backed-up in to the version control repository via the Salesforce IDE / Ant migration tool.

Module Testing Business Config Only • Controlled environment.• Formal releases are issued in to this environment with the identified release content / functionality.• Business conducts Module/release testing in this controlled environment.• Releases are made as Change Sets from ‘Control’ environment.• Stays for the life of the project.• Receives isolated data migration loads to support testing (repeatable process).

Integration testing IT Config Only Integration team to conduct end to end testing with other internal systems and validate relevant test cases. Other characteristics identical to Module testing Sandbox.

UAT Business Full Created from Production in order to conduct UAT with a full set of data.Data load testing and verification takes place in this environment prior to UAT.

Training Business Config Only For end-user training development and training execution. Needs to remain after implementation, for ongoing training.Data needs to be controlled/need to be able to restore a stable set of training data between each course.

Production Business N/A The production environment

Rollback IT Config Only A clone of production created prior to a production release, primarily used to accommodate rollback scenarios. Training environment could also be used for this purpose.

Multi-Project Delivery Cycle with 6 Sandboxes

Production Instance

Production Support

Staging

live

full copy

configuration-only, test data

configuration-only, training data

legend

DevIntegration

Long Projects

Training

Dev

Dev

Dev Rollup / Integration

Short Projects

developer

Environment Planning

Developer sandbox

Configuration-only sandbox Full copy sandbox

Development § Good Fit § Good Fit§Perfect for having configuration and development on the same sandbox

§ slower to copy§ giving developers access to data may not be ok

Testing § unit tests§ apex tests

§ best for Feature/ Unit test§ load minimal data for regression

§ Best for production debugging§ Load testing

Testing external integrations

§ not a good fit § special cases only§ use sample or subset data§ works well if using external ids

§ frequently required§ external system expects full

production data to be present

Volume / UAT § not a good fit § sometimes appropriate if testing against subset of production data is acceptable, e.g. regional

§ usually required§ validation of new apps against

production config and data

Sandboxes Available / Edition

§ EE – 1 sandbox§ UE – 1 sandbox

§ UE – 5 config sandboxes§ Note: Can purchase up to 6

config only sandboxes

§ UE – 1 full sandbox§ Note :Can purchase up to 3

full sandboxes

Considerations § Small 10 MB § 500 MB storage § Same as production

Choosing a type of Sandbox

Environment Planning§ Development environments required to support

Development process– Create manageable number of development Sandboxes

– Each Sandbox is its own environment and they do not share configuration, code or data

– Provision users to appropriate sandboxes based on development activities

§ Considerations– Too many environments lead to management and

synchronization chaos

– Too few environments lead to a chaos in managing concurrent activities thereby leading to an elongated development time

– POC could be done on developers org

Environments

7/15/14 38

Establish Configuration Baseline

Dev

Integration Testing

Production

Training

Consolidated Dev

Environment

Full Sandbox

Production Org

Config-only Sandbox

UAT | Pre-production

QA

Control

Develop in DEV

Sandbox Refresh From Production

Note: Any changes to base line configuration should trigger a sandbox refresh cycle

Rollback

Controlling Change

§ Before migrating any data changes from Sandbox to production you should always make a back-up copy of your production organization data– Data back-ups: Setup | Data Management | Data Export

– Data exports can be run immediately or scheduled

– Use the Data Loader to restore the data to the previous state

– Appropriate for territory changes, assignment changes (i.e. account or case transfers), etc.

§ Copies of your configuration can be made using tools such as Snapshot

§ Control administrative access to your org– Allow only a certain number of users full access to make configuration and data

changes

– Implement an oversight committee to review/approve changes before they are made

– “Flip” the profile for Users if necessary to toggle between admin and standard user privileges – use custom profiles to define specific parameters for what a User can do without full fledged Admin access

Some Facts About Sandboxes§ Config / Dev sandboxes can be refreshed once every day

§ Full sandbox refresh period is 29 days after previous refresh date

§ Sandbox refresh are queued and takes time to complete

§ A sandbox is not a point-in-time snapshot of production. Keep production changes down when copying.

§ Sandbox delete option available when maximum limit reached

§ User name and email address appended with sandbox name

§ New users created in sandbox count against number of licenses

§ Sandboxes after every refresh may appear on different instance and URL may vary.

§ Data copied from production will have matching object Id

Note: Please refer to development life cycle document or help text for details

Key roles§ Environment Owner

– Who: A Person nominated as the owner of an environment.

– Responsibility: • In control of the assigned environment (i.e. Admin access).

• Decides on granting other user access.

• Coordinate activities in the environment (such as data loads).

• Decision maker on accepting an available release.

• Can make change requests and raise defects to be made available in next release.

• Prepare and manage sample data for environment

§ Administrator/s– Who: Person/team responsible for admin activities of an environment

– Responsibility:• Maintain integrity of environment

• Delegate administrative responsibility to individual/groups

• Manage users and access rights.

• Manage refresh cycles and data seeding

• Manage inbound / outbound connections for environments

Establish Process and Governance§ Development Process

– What is the rollout path for each change request?

– Does it require upstream or downstream migration?

§ Validation and approval process– What are the prerequisites for a change to be released to an environment?

– What procedures to be followed and how it is communicated?

§ Purpose of version control– Repository for codebase for developers?

– Repository for Metadata of non development environments?

§ Deployment options – Standardize deployment process

– To use or not to use version control for deployment?

– Cloud deployment Vs continuous integration?

– Using IDE for deployment?

– Deployment to locked down environments?

Tools: Selecting the right tools for the job

§ Salesforce.com Tools and Framework– Force.com IDE (Eclipse based)

– Change Sets (Cloud Deploy)

– Ant migration tool

§ 3rd Party Tools– Dreamfactory Monarch: Copy, merge,

migrate and archive data between orgs

– Dreamfactory SnapShot: View, compare and push configurations (Metadata)

§ Customer Tools– Version Control

– Change Management

Dev

Test

Dev

Version Control

Project Branch

BASIC ADVANCED

Cloud Deploy IDE Ant Version

Control

Build, Test, And Deploy From One Tool

IDE

Single Project View

XML Application

View

Rich Code Editors for Visualforce and Apex code

Promote Changes Seamlessly with Change Sets

BUSINESS USERS

ADMINS ANDDEVELOPERS

PRODUCTION

1. Create Sandbox

2. Make Changes

3. Deploy Change Sets

Tool Selection: Change Sets§ Deployment tool in the cloud§ Predicts code/config dependency§ Does not require knowledge of Eclipse,

ANT, EDI, etc.§ Capabilities:

– Authorize inbound/outbound connections– Assemble a set of metadata in source org– Upload change set to target– Clone change set– Deploy a Change Set

§ Limitations– Manual and process driven– Cannot delete or rename – Some object are not available– Not a snapshot of metadata– 2,500 components, total file size of 400 MB.

§ Disconnected process – Developers upload changes– QA/ Release Managers download and apply

changes

Using Snapshot for Migration

Tool SelectionTools Pros Cons

Ant Migration Tool

•Automation possible

•Full export and deploy possible

•Ideal backup tool / syncing with version control

•Customized to integrate with Version Control

•Manual process of identifying migration artifacts

•Deployed directly to target environment

•No audit trail of migrated artifacts

•No dependency check until deployment

•Administrative overheads

Force.com IDE

•Easy to deploy individual artifacts

•Connects with version control

•No way to package artifacts for deployment

•Artifacts cached on desktop and needs syncing with server

•Risk of deploying local version of artifacts

•No dependency check until deployment

BASIC ADVANCED

Cloud Deploy IDE Ant Version

Control

Continuous Integration: Example

Note: Need to establish release windows for each environment including production and take Salesforce maintenance window into consideration.

Timed build and release cycle for each environment

Release Cycle

Tool Selection: Change Set Vs Automation

§ Simple and easy to use / manage

§ Convenient for developers and admin to work together

§ Build and deployment will be a manual process

§ Controlled release process

§ Ad hock release possible

§ Complex and requires customization

§ Admin requires development (Ant, API etc) tools/skills

§ Automation possible with strict adherence of process and governance

§ Identifying delta becomes a challenge and full migration required

7/15/14 51

Version Control

Development

Integration

UAT

Production

Change Set

Version Control

Integration

Staging

Production

Development

Metadata

Metadata

Code and/or

Metadata

Code & Metadata

Code & Metadata

Code & Metadata

Continuous Integration

Tools Comparison SummaryNeed

Force.com IDE ANT based Migration Tool Change Sets

Configuration Changes (Add/ Update)

§Great Fit § Good Fit§Perfect for having configuration and development on the same sandbox

§Good Fit§Perfect for having a disconnected process where users don’t have to be in two orgs for performing deployment§IDE and ANT has more change capabilities that Change Sets

Code Changes (Add/ Update)

§ Great Fit § Good Fit § Great Fit

Deleting Configurations and Code assets

§ Good Fit § Good Fit § Not a Good Fit

Nightly Automated pushes

§ not a good fit § Perfect fit for batch releases § Not a good Fit

Less Programming/ ANT / IDE Skills

§ Good Fit (Can use Change Sets as well if performing migration from Sandbox to Prod.)

§ Not a Good Fit (Needs programming and ANT skills)

§ Perfect for organizations not having resources knowledgeable with IDE or ANT

Automated Test Coverages

§ Not a Good Fit § Great Fit § Not a Good Fit

Release Types Identified§ Controlled / Periodic Release

– Strictly adheres to process

– Change flows through every downstream environment

– Tested and approved by every environment owner

– Goes through integration and UAT

§ Quick / Hot Fixes– A fast rollout path typically to address a burning production issue

– Release path to be defined at the time of evaluating change

– UAT may or may not be required depending on nature of change

– Downstream environment owner to approves based on upstream testing results

– Deployment should flow through all down stream environment

– Could be applied directly in production and then replicated to other environments

§ Rollback– Production rollback is not a straight forward task

– Prepare a rollback environment that is a copy of production

– Release manager responsible for preparing rollback change sets

– Cannot rollback new artifacts deployed and needs to be removed manually

– Apex code could be removed in production only after it is disabled

Sample Path to Production Matrix

§ Change control process to determine appropriate path to production

§ Measure change type and release type based on complexity

§ Consider validation requirements in determining path to production

§ Ensure path to production environments are in sync

§ Determine if concurrent testing permissible or should be serialized

§ Yes. It is ok to apply certain changes directly in production. Be judicious.

§ Changes from production applied to sandbox using change sets or refresh cycle

§ Identify rollback scenarios and prepare for rollback

§ Identify a tool to capture change request and track progress

Change Type

Release Type

Con Dev QA INT UAT PRD

Simple Immediate Yes Yes No No Yes

Medium Minor Yes Yes No Yes Yes

Complex Major Yes Yes Yes Yes Yes

Hot Fix Production No No No No Yes

Note: Table above shows a sample path to production chart. These are suggestive guidelines

Dev

Integration Testing

Production

TrainingConsolidated Development

Full Sandbox

Production Org

Config-only Sandbox

UAT | Pre-production

Environment Plan and Release Path

QA

Control

Change Set From Controlled environment

IDE / Change set from development environment

Definition: Constant Development, Moving Environments.

Change Requests and Defect Management• All environment owners could log Defects and submit Change Requests via the Defect Management and Change Management processes, respectively. • A Release Manager responsibility is assigned within the development team.• Defects and Change Requests are worked on in the Development environments and are included in the next release as per the above release path.

Definition: Holds latest release.

Definition: Controlled environment quality assurance and incremental testing.

Definition: Data Migration testing, followed by UAT and pre-production.

Definition: Training Environment. Relevant releases deployed for incremental training material development.

Definition: Utilised to conduct integration testing with other systems

DevDev

Rollback

Definition: Refresh Prior to release. IDE/change sets for rollback

Sandbox Refresh

Developer POC

(Full Sandbox)

QA

(Full Sandbox)

Eclipse PackageCreation

SubVersion

PackageInstallation

Testing(Full Sandbox)

UAT

(Full Sandbox)Production

Subversion Package is installed in each Sandbox and tested.

Training

(Full Sandbox)

Integration

(Full Sandbox)

Developers(Dev Sandbox)

30+

Download to Eclipse

Release Management at

Sandbox

Dev QA Prod

Individual Project /Dev Environments

Functional Dev Project Team 2

Functional Dev Project Team 1

Apex and VFDev

Integration Dev

Legend

Deployment by Production Deployment Team

Deployment by Project/Dev Team

Managed by Production System AdminSandbox refresh from Production after each Release to ensure they are current with Production environment

Sandbox refreshed from Production as and when required for additional testing

Full Copy SandboxDev/Configuration Only Sandbox

Testing Bugs Reported in Production

•Data Load•Data Cleansing •Integration

•Project Testing for Sprints

•UAT•Training

1. Having 5 Full Copy Sandbox helps leverage environments respectively as required based on Monthly Refresh Cycles provided by Salesforce.com and Project timelines

2. QA is separated from UAT allowing less impact on the project timelines and Monthly release cycles.

3. Splitting Data/Integration helps in managing activities independently for ETL development and testing.

4. Support process would be more streamlined and can be conducted with Production data as bugs are reported independently on release cycles

5. Project Stream have their individual sandbox to assist in Quality testing using full data from production as oppose sample data, allowing team to perform regression testing for each sprint as oppose to waiting for final QA cycles.

Release Using Change Set

§ Change control process governs every stage of release management

§ Developer creates change set on one or many development environments

§ Release manager upon approval by owner deploys inbound change sets to consolidated environment

§ System testing performed to validate build on Consolidated environment

§ Release manager creates outbound change set on consolidated development environment

§ Uploads for deployment to QA environment . Change set locked down at this point.

§ QA environment owner approves and QA admin deploys changes

§ Once QA validation complete release manager queues up change set for Integration / UAT

§ Deployed to UAT or downstream environment upon approval by environment owner

§ Defects goes back to development and follows the path until production ready

Dev

Dev

DevConsolidated Development

QA

Integration

UAT | Pre-production

Production

Key role§ Environment & Release Manager

– Who: A single person across the project who defines the content of each release and tracks the status of each environment from a release perspective.

– Responsibility: • In control of defining and communicating the content of a release.

(e.g. Release 3.2 covers delivers 101-121, defects 11-15, Change Requests 32-35).

• Applies the release to each environment ( where the owner has accepted the release).

• Tracks the status of each environment from a release perspective

(e.g. Module testing is on v3.0, SIT & UAT are on v2.3).

• Keeps track of change sets status in source and target environments

Best Practice &

Recommendations

Salesforce.com Environment & Release Management Best Practice

For further content on development best practice, tools and techniques, please see:§ “Development Lifecycle Guide – Enterprise Development on the Force.com Platform”

http://www.salesforce.com/us/developer/docs/dev_lifecycle/salesforce_development_lifecycle.pdf

Change Management

1. Always Open a Change Request.– Use cases to capture and track support / change request

– Support Manager: “If its not in the system then it doesn’t exist...No Exceptions”

2. All Change Requests Must Follow Development Lifecycle– All Change Requests must be analysed via development process, irrespective of simplicity

– Analyse downstream impact first

– e.g. Given a new change request, modifying a validation rule may make sense in isolation, but can cause runtime exceptions in downstream custom code that relied on this validation. Many similar examples exist

3. Take Admin Access Seriously– Strictly follow procedures and follow administrator checklist

– A “Simple” configuration change can break the system

4. Systemize Change Request Management– Adhere to process, reviews, approvals and associated documentation

– Determine dependencies and release path for change request

– Identify, if test environments requires refresh and adjust timeline accordingly

Change Management

5. Regular (Scheduled) Release Window– Defect fixes and change request artefacts are released in to Production during a pre-planned

recurring release window

– Ad-hock releases only an exception

6. Collaborate– Support and Change Requests are likely to involve multiple teams:

• Define Support Levels and support teams

• Business stakeholders reviewing and approving changes

7. Change Committee– A Change Committee should be established

– Ensure that due process has been followed for support and change requests

– Make decisions on major releases, exceptions and prioritize change requests

8. Post Release Activities– Release manager responsible for defining rollback scenarios and approach

– Communicate new releases to user community

Environment Planning§ Do the baseline build and configuration in Production

§ Refresh configuration from the production org into separate developer / configuration only sandboxes

§ Lockdown on all sandbox environments and only open up development environment

§ Developer work on development, test their work, and synchronize their finished changes to version control

§ Completed changes from development pushed into consolidated development environment

§ Perform system testing before packaging for promotion

§ Change set from Consolidated Dev uploaded to test environments

§ Governance required to manage on going changes where lead architect, environment owner, business representatives approve changes.

§ Eventually, approved changes are applied to downstream environments

7/15/14 65

Environment Planning§ Combine multiple streams of development to minimize need for

development sandbox

§ Identify data seeding requirements and prepare data for Dev/Config only sandboxes

§ Prepare sample data sets for Dev / module / QA / integration testing.

§ Prepare data loader scripts to load sample data test environments

§ Utilize full sandbox for User Acceptance Testing (UAT)

§ Consider sequencing integration testing and QA/Module testing

§ Identify large data volume testing scenarios and perform those on full sandbox prior to / part of UAT

§ Inactive users from production could be activated in sandbox. Dev Admin / QA Admin may require “Modify All” special privileges.

§ Evaluate need for additional sandbox environments

Development Practice§ Use latest versions of tools

§ Enforce standard versions of Eclipse IDE across development– Reduces risks of unavailable API

§ Create deployment notes for deployment– Dependency Matrix describe deployment dependencies

– Package dependencies / sequence of deployment

§ Enforce and Educate– Publish and Distribute Development Process and Guidelines

– Educate resources on Technology and Tools

– Enforce periodic testing to mitigate risks

– Publish Code best practices, Testing Methodology

– Enforce accountability

7/15/14 67Best Practices

Development Practice§ Coding Practices

– Enforce policy to sync code periodically with version control and SF org

– Remember to refresh from server before updating code

– Adherence to coding standards and best practices

– Periodic code reviews & encourage inline commenting

§ Test Coverage– Develop test classes and enforce higher test coverage

– Enforce test coverage as early and often

– Identify key test scenarios as early as design / analysis phase

– Implement test code for all scenarios without exception

– A well thought out test code could be relied upon to detect broken functionality

– Concurrent / overlapping projects requires thorough test code addressing all scenarios

– Do not simply try and meet minimum requirement of 75% coverage

– 80% coverage is preferable and should be a byproduct of covering all scenarios

– Include negative test scenarios

– Ensure test code is independent and does not rely on data from environment

– Ensure test code implements data seeding

Release Management

Note: A regular refresh of all sandboxes from Production should be planned by the release manager to minimize out of sync issues.

Release Management§ Start with Change set, firm up process and extend to automation

§ Change management process defines release path

§ Change management process to introduce a unique # to track changes

§ Introduce naming convention for change sets and keep name descriptive– Include project name or description of issue fixed

– Change Request # + Description, CR-1234-CareGroupEnhancement

§ Differentiate between enhancement and a fix

§ Perform system testing on Consolidated Dev environment

§ Release manager to coordinate deployment of change set with environment owner.

§ Environment owner / admin deploy changes only when approved

§ Environment owner responsible for validating release and approval for downstream release

§ Repackage change set by cloning, prefix a release increment to package name– E.g.: R2-CR-1234-CareGroupEnhancement

§ Change set applied to production only after validated and approved on all up stream environment.

Release ManagementRelease Lead Time

§ Consider reasonable lead-time for each release.

§ Include sandbox refresh time (as required) into time estimates§ Sandbox refreshes are queued and could take about 24 hours at times to refresh

§ Full sandbox refresh could take longer time depending on data volume

§ Remember full sandbox could be refreshed once every 29 days

§ Consider data seeding requirements for Dev/Config sandboxes

§ Include time for setting up users for testing and administration

§ Allow time for applying release and resolving any conflicts / troubleshooting.

§ Release effort may vary depending on complexity of release

§ Manual config, managed packages, artefacts not supported by metadata API

§ Keep all environments / work streams on the same release

Training & Communication

Communication Strategy

§ A comprehensive communication strategy:– Is targeted training for specific groups or roles– Assesses needs of each audience and is based on functional, cultural or

geographical needs

– Allows users to prepare before hand (e.g., web based tutorials, etc.)

– Provides formal and informal training programs for continuous improvement

– Utilizes the right type of training/communication tool for the size and scope of the release

§ Suggested training and communication tools:– Class room training

– Web-based training/recordings

– Newsletter communications/Tips & Tricks

– Home page Messages & Alerts

§ The technology is not difficult to learn

§ Focus more on “why” and “what”, not “how” when training

§ Address uncertainty on why and when to use the technology§ Considerations

– Audience – users, evangelists, sponsors

– Remote live vs. recorded

– Train-the-trainer approach can leverage evangelists

§ Additional Assets– FAQs

– Videos

– Quick reference guides

User Training Guidance

Supplement Training with Premier Learning Paths

Ongoing Support

Governance Functions: Support TiersLevel Type Description

Tier 1 Internal networkers (Change Agents)

Power Users and Champions• Advanced users who understand the system• The “go to” person in their community• Vocal advocate of support

End Users• Day-to-day users of the application• Can be advocates to their peers

Tier 2 Internal Help Desk • Formalized point of contact for technical issues

• Change agents filter common FAQs• Change agents also help identify training

improvement opportunitiesTier 3 SFDC administrator • Formal escalations from internal help desk

• Also performs basic configuration (reports & Dashboards), data loads, scheduled processes, etc.

Tier 4 Salesforce.com Premier Support

• Escalation for Tier 3 to help resolve issue

Ongoing Support Model cont.

§ Leverage custom application to manage changes§ Leverage your internal Help Desk§ Develop skilled administrators & developers – Add Value§ Delegate administration duties across business lines§ Automate business processes using workflow to streamline support§ Build Change Control Board to streamline processes§ Create FAQs to reinforce how-to guidance§ Institute Lunch & Learn sessions to help drive and reinforce adoption§ Examples of types of communication/messages include:

– Messages of the day (from Executive Sponsors, VPs, etc.) – New features– Upcoming system changes/ maintenance– Tips and tricks– Training– Events

Next Steps§ Develop process for change management

§ Advertise for top to bottom & bottom up adoption

§ Evaluate environment needs to meet release requirements

§ Define change complexity and release path matrix

§ Define test environments and migration path

§ Evaluate manual Vs automated release

CoE ResponsibilitiesStandards & Best Practices Reporting/Dashboard Templates

SME Knowledge & Training Materials Cross-business Coordination (Projects)

New Functionality Test & Deployment Approach Security & Data Sharing Model

Data Integration Approaches and Execution Subscription & Vendor Mgmt (AppExchange)

New Unit Implementation Guidance & Support New Product Feature Evaluation

Business Unit 1

Business Unit ResponsibilitiesBusiness Requirements & Process Mapping Salesforce.com New Release Review

Business-unit Specific Project Governance Reporting & Measurements

Basic Configuration Business Data Validation

User Training and Support Adherence to Best Practices

CoE Participation User Management (Add, Delete, Update)

Business Unit 2 Business Unit 3 Business Unit N

Governance: Center of Excellence