Agenda
§ Introductions
§ Change management
§ Release management
§ Process and governance
§ Environment management
§ Best practice and recommendations
§ Training and communication
§ Ongoing support
§ Next steps
§ Q & A
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
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
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
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
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
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
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
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