Uploaded byAdilPatel34
PPTX, PDF1,196 views

Change, Release, Management In-Depth vTom.pptx

This document provides an overview of change and release management for a Salesforce implementation. It discusses collecting change requests, tracking requests, prioritizing requests, development architecture, QA/UAT, approvals, communications, and training. It also covers change management processes, different types of changes, who should be involved, and steps for effective change management. Additionally, it outlines considerations for release management including deployment cadence, environment strategy, training/communications, and ongoing support models.

Embed presentation

Downloaded 33 times
Change & Release Management Tom Nepa Success 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 Vision Strategy 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 1 2 Deployment Size & New Project Cadence Evaluation 3 Environment Strategy 4 Training & Communica- tion 5 Ongoing 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 Flow SFDC User SFDC Admin Change Control Board IT Submits change request Reviews request Approved? Determines release timeframe Analyzes request and timeframe IT required? Configure feature/ functionality Sandbox Environment Sandbox required? Configure feature/ functionality Production Environment Notifies CMM request completed Conducts Testing (end-user & IT) Moves changes to production environment Communicates changes to end-users User notified
Configuration Changes Many Few Simple Difficult Level of Effort Source: Faulkner 2006 Immediate Releases • Implement immediate changes • Owned by individual sub-group • Minimal impact to the production floor Minor (Monthly) Releases • Minor changes impacting two or more groups • Thrice as often as a Major Release • Minor impact to training and production Major Releases • 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 Types Does not dilute the value of force.com flexibility
Release Management: Definitions Release 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 -8 Final 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 0 Days -5 Days -8 QA Mod Test TRN INT UAT Environment Freeze ... Note: Days are suggestive
Appendix
Process & Governance
Process Management Methodology Development & Release Management Environment Management 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 Development Tools 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 Code and Schema Metadata API Force.com Migration Tool http://wiki.developerforce.com/index.php/Migration_Tool Cloud Deploy Easy Tool for Admins to Migrate Changes
Sandbox Replicates Your Salesforce.com Organization Production Salesforce.com Organization Development Sandbox: Create a separate on-demand application environment for… Training Testing (QA)
Sandbox: Types, Features, Uses Features Best For… Developer • Copy of configuration/code • No data copied • 10 MB data storage • Development • Testing new features • Apex tests Configuration Only Full • Copy of configuration/code • No data copied • 500 MB data storage • Copy of configuration /code • Copy of active data and files • Same storage limits as the production organization • Testing new features • Loading standard data for regression testing • Limited use for staging/UAT • Staging / UAT • Validating new apps against active configuration and data • Testing external integrations • Training
Environment Definitions Sandbox 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 systemsand 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 legend Dev Integration Long Projects configuration-only, test data configuration-only, training data developer Training Dev Dev Dev Rollup / Integration Short Projects
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 Production Org Full Sandbox 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 IDE Deploy 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 AND DEVELOPERS 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 Selection Tools 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 Timed build and release cycle for each environment Note: Need to establish release windows for each environment including production and take Salesforce maintenance window into consideration. Release Cycle
Tool Selection: Change Set Vs Automation Change Set • 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 Continuous Integration • 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 Development 7/15/14 51 Version Control Integration UAT Production Version Control Integration Staging Production Development Metadata Metadata Code and/or Metadata Code & Metadata Code & Metadata Code & Metadata
Tools Comparison Summary Need 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 Note: Table above shows a sample path to production chart. These are suggestive guidelines • 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
Integration Testing Production Training Consolidated Development Full Sandbox Production Org Config-only Sandbox UAT | Pre- production Environment Plan and Release Path Control 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. QA 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 Dev Dev Rollback Definition: Refresh Prior to release. IDE/change sets for rollback Change Set From Controlled environment IDE / Change set from development environment Sandbox Refresh
Developer POC (Full Sandbox) QA (Full Sandbox) Eclipse Package Creation SubVersion Package Installation 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 FunctionalDev Project Team 2 FunctionalDev Project Team 1 Apex and VF Dev Integration Dev Legend Deployment by Production Deployment Team Deployment by Project/Dev Team Managed by Production System Admin Sandbox 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 Sandbox Dev/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 Dev Consolidated 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 67 Best 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 Management Release 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 Tiers Level 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 opportunities Tier 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
Standards & Best Practices SME Knowledge & Training Materials CoE Responsibilities Reporting/Dashboard Templates 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 Responsibilities Business Requirements & Process Mapping Business-unit Specific Project Governance Basic Configuration User Training and Support CoE Participation Salesforce.com New Release Review Reporting & Measurements Business Data Validation Adherence to Best Practices User Management (Add, Delete, Update) Business Unit 2 Business Unit 3 Business Unit N Governance: Center of Excellence

More Related Content

PDF
Release and Enviromental Management
bySalesforce Partners
 
PDF
Manage Salesforce Like a Pro with Governance
bySalesforce Admins
 
PDF
Performing a successful technical debt assessment in Salesforce
byCoforge (Erstwhile WHISHWORKS)
 
PDF
Webinar: Take Control of Your Org with Salesforce Optimizer
bySalesforce Admins
 
PDF
DevOps Center_ArchitectGroup
byAmeyKulkarni84
 
PDF
Salesforce CI/CD - A strategy for success
byYassine ELQANDILI ☁
 
PDF
Manage Development in Your Org with Salesforce Governance Framework
bySalesforce Developers
 
PPTX
Salesforce Development Best Practices
byVivek Chawla
 
Release and Enviromental Management
bySalesforce Partners
 
Manage Salesforce Like a Pro with Governance
bySalesforce Admins
 
Performing a successful technical debt assessment in Salesforce
byCoforge (Erstwhile WHISHWORKS)
 
Webinar: Take Control of Your Org with Salesforce Optimizer
bySalesforce Admins
 
DevOps Center_ArchitectGroup
byAmeyKulkarni84
 
Salesforce CI/CD - A strategy for success
byYassine ELQANDILI ☁
 
Manage Development in Your Org with Salesforce Governance Framework
bySalesforce Developers
 
Salesforce Development Best Practices
byVivek Chawla
 

What's hot

PDF
Shift Left - Approach and practices with IBM
byIBM UrbanCode Products
 
PDF
Building a Center of Excellence for your Salesforce crm team
byBuyan Thyagarajan
 
PDF
Salesforce x DevOps 101.pdf
byObidjon Komiljonov
 
PPTX
Azure Migration Program Pitch Deck
byNicholas Vossburg
 
PPTX
Azure Devops Build Tools for Powerapps
byJoost Veldhuis, MSc
 
PPTX
Introducing SAFe® 5
byScaled Agile, Inc.
 
PDF
Agile sdlc
byBhawani N Prasad
 
PDF
Salesforce.com Org Migration Overview
byShell Black
 
PPTX
Azure DevOps Best Practices Webinar
byCambay Digital
 
PPTX
Microsoft Cloud Adoption Framework for Azure: Governance Conversation
byNicholas Vossburg
 
PDF
Introduction To Jira
byHua Soon Sim
 
PPTX
Leveraging Azure DevOps across the Enterprise
byAndrew Kelleher
 
PDF
DevOps, Common use cases, Architectures, Best Practices
byShiva Narayanaswamy
 
PDF
Jira as a Project Management Tool
byPaolo Mottadelli
 
PPTX
DevOps and Tools
byMohammed Fazuluddin
 
PPTX
Release Management: Successful Software Releases Start with a Plan
byconnielharper
 
PPTX
DevOps Overview
bySagar Mody
 
PPTX
Best practices for implementing CI/CD on Salesforce
byAIMDek Technologies
 
PPTX
Introduction to DevOps
byMatthew David
 
PDF
DevOps - A Gentle Introduction
byGanesh Samarthyam
 
Shift Left - Approach and practices with IBM
byIBM UrbanCode Products
 
Building a Center of Excellence for your Salesforce crm team
byBuyan Thyagarajan
 
Salesforce x DevOps 101.pdf
byObidjon Komiljonov
 
Azure Migration Program Pitch Deck
byNicholas Vossburg
 
Azure Devops Build Tools for Powerapps
byJoost Veldhuis, MSc
 
Introducing SAFe® 5
byScaled Agile, Inc.
 
Agile sdlc
byBhawani N Prasad
 
Salesforce.com Org Migration Overview
byShell Black
 
Azure DevOps Best Practices Webinar
byCambay Digital
 
Microsoft Cloud Adoption Framework for Azure: Governance Conversation
byNicholas Vossburg
 
Introduction To Jira
byHua Soon Sim
 
Leveraging Azure DevOps across the Enterprise
byAndrew Kelleher
 
DevOps, Common use cases, Architectures, Best Practices
byShiva Narayanaswamy
 
Jira as a Project Management Tool
byPaolo Mottadelli
 
DevOps and Tools
byMohammed Fazuluddin
 
Release Management: Successful Software Releases Start with a Plan
byconnielharper
 
DevOps Overview
bySagar Mody
 
Best practices for implementing CI/CD on Salesforce
byAIMDek Technologies
 
Introduction to DevOps
byMatthew David
 
DevOps - A Gentle Introduction
byGanesh Samarthyam
 

Similar to Change, Release, Management In-Depth vTom.pptx

PDF
Salesforce Application Lifecycle Management presented to EA Forum by Sam Garf...
bySam Garforth
 
PDF
Change Management Powerpoint Presentation Slides
bySlideTeam
 
PDF
Agile Release Management Best Practices
byAnmol Oberoi
 
PDF
From Sandbox To Production: An Introduction to Salesforce Release Management
bySalesforce Developers
 
PPTX
Release & Change management in salesforce
byKalyan Lanka ☁
 
PPTX
Release management transformation - let's start
byBeyrem CHOUAIEB
 
PPT
The Year of Living Dangerously: Extraordinary Results for an Enterprise Agile...
bySteve Greene
 
PPT
Scrum Gathering 2008 Stockholm - Salesforce.com
bySteve Greene
 
PDF
Change Management Budget Control PowerPoint Presentation Slides
bySlideTeam
 
PPT
The Year of Living Dangerously: Extraordinary Results for an Enterprise Agile...
byguest6a0f70
 
PDF
5 practical ways to efficient change and release management
byEnov8
 
PPTX
Dallas Salesforce User Group - January 2012 Meeting: Release Management
byKevin Richardson
 
PDF
The World of Agility
bySalesforce Partners
 
PPTX
Release Management: Managing Your Internal Releases
byJoshua Hoskins
 
PDF
Agile Release Management for Fast Moving Enterprises
byDreamforce
 
PPTX
changemanagementpowerpointpresentationslides-210607120855.pptx
bySamuelLee440194
 
PDF
Admins are Critical Change Agents
bySalesforce Admins
 
PPT
Dreamforce 2008 : Transforming IT Success with Agile Development Processes
bySteve Greene
 
PPT
Q Con 2008 - Unleashing the Fossa
bySteve Greene
 
PPT
Agile Leadership Summit: Unleashing The Fossa : Scaling Agile in an Ambitious...
bySteve Greene
 
Salesforce Application Lifecycle Management presented to EA Forum by Sam Garf...
bySam Garforth
 
Change Management Powerpoint Presentation Slides
bySlideTeam
 
Agile Release Management Best Practices
byAnmol Oberoi
 
From Sandbox To Production: An Introduction to Salesforce Release Management
bySalesforce Developers
 
Release & Change management in salesforce
byKalyan Lanka ☁
 
Release management transformation - let's start
byBeyrem CHOUAIEB
 
The Year of Living Dangerously: Extraordinary Results for an Enterprise Agile...
bySteve Greene
 
Scrum Gathering 2008 Stockholm - Salesforce.com
bySteve Greene
 
Change Management Budget Control PowerPoint Presentation Slides
bySlideTeam
 
The Year of Living Dangerously: Extraordinary Results for an Enterprise Agile...
byguest6a0f70
 
5 practical ways to efficient change and release management
byEnov8
 
Dallas Salesforce User Group - January 2012 Meeting: Release Management
byKevin Richardson
 
The World of Agility
bySalesforce Partners
 
Release Management: Managing Your Internal Releases
byJoshua Hoskins
 
Agile Release Management for Fast Moving Enterprises
byDreamforce
 
changemanagementpowerpointpresentationslides-210607120855.pptx
bySamuelLee440194
 
Admins are Critical Change Agents
bySalesforce Admins
 
Dreamforce 2008 : Transforming IT Success with Agile Development Processes
bySteve Greene
 
Q Con 2008 - Unleashing the Fossa
bySteve Greene
 
Agile Leadership Summit: Unleashing The Fossa : Scaling Agile in an Ambitious...
bySteve Greene
 

Recently uploaded

PPTX
WinRAR Crack 7.13 Final Mac Keygen 2026 Download [Latest] Software.pptx
bysanaolikhnn
 
PPTX
Audio Hijack 4.5.6 Crack Plus License Key Full Activated Software.pptx
bysanaolikhnn
 
PPTX
Wondershare Filmora 15.0.11 Crack for Mac Key Full Download [Latest] pptx
bysanaolikhnn
 
PPTX
iStat Menus 7.20 Crack for MacOS 2026 Full Version [Latest] pptx
bysohlakhnn
 
PPTX
AnyTrans for iOS 8.9.14.20251127 With Crack for MacOS [Latest] pptx
bysohlakhnn
 
PPTX
Presentation - The First Christmas Story.pptx
byyunilyngallardo1
 
PPTX
Artificial Intelligence basic notes for engineering.pptx
byKiranG764628
 
PPTX
Become a Professional UI/UX Designer by Learning How to Create Beautiful, Use...
bykandi4191
 
PPSX
Gas Turbine simulation in thermoflow software PRO Overview.ppsx
byNaji Abdullah
 
PPT
Affect of World Tourism on Climate Change.ppt
byhaybars41
 
PPTX
Optimization of Lightweight Concrete Using Vermiculite, Silica Fume & Naphtha...
byinfernowolf18
 
PPTX
Dropshare 6.8.0 Crack for macOS Download
bybhattiaraz50
 
PDF
Architect Saleem khattak (Archi) Portfolio
byArSaleemktk
 
PPT
THEORY OF ARCHITECTURE - LECTURE NOTES FOR REFERENCE
bykanakatharak1
 
PDF
Farm-structures-housing-cow-calves-youngstock_compressed.pdf
byVinMao1
 
PDF
Casual Winter Collection 2024-25 Style Guid
byReshma
 
PDF
WEDDING STYLING / INTERIOR DESIGN PORTFOLIO 2025 SK
byShahira K
 
PDF
Morgenbooster_Drakonheart_Designing_for_creative_kids.pdf
by1508 A/S
 
PPTX
Test Powerpoint with embedded video.pptx
bystuartfeldman9
 
PPTX
Construction area photographs site visit
byArpitJha13
 
WinRAR Crack 7.13 Final Mac Keygen 2026 Download [Latest] Software.pptx
bysanaolikhnn
 
Audio Hijack 4.5.6 Crack Plus License Key Full Activated Software.pptx
bysanaolikhnn
 
Wondershare Filmora 15.0.11 Crack for Mac Key Full Download [Latest] pptx
bysanaolikhnn
 
iStat Menus 7.20 Crack for MacOS 2026 Full Version [Latest] pptx
bysohlakhnn
 
AnyTrans for iOS 8.9.14.20251127 With Crack for MacOS [Latest] pptx
bysohlakhnn
 
Presentation - The First Christmas Story.pptx
byyunilyngallardo1
 
Artificial Intelligence basic notes for engineering.pptx
byKiranG764628
 
Become a Professional UI/UX Designer by Learning How to Create Beautiful, Use...
bykandi4191
 
Gas Turbine simulation in thermoflow software PRO Overview.ppsx
byNaji Abdullah
 
Affect of World Tourism on Climate Change.ppt
byhaybars41
 
Optimization of Lightweight Concrete Using Vermiculite, Silica Fume & Naphtha...
byinfernowolf18
 
Dropshare 6.8.0 Crack for macOS Download
bybhattiaraz50
 
Architect Saleem khattak (Archi) Portfolio
byArSaleemktk
 
THEORY OF ARCHITECTURE - LECTURE NOTES FOR REFERENCE
bykanakatharak1
 
Farm-structures-housing-cow-calves-youngstock_compressed.pdf
byVinMao1
 
Casual Winter Collection 2024-25 Style Guid
byReshma
 
WEDDING STYLING / INTERIOR DESIGN PORTFOLIO 2025 SK
byShahira K
 
Morgenbooster_Drakonheart_Designing_for_creative_kids.pdf
by1508 A/S
 
Test Powerpoint with embedded video.pptx
bystuartfeldman9
 
Construction area photographs site visit
byArpitJha13
 

Change, Release, Management In-Depth vTom.pptx

  • 1.
    Change & Release Management TomNepa Success Manager
  • 2.
    Agenda ■ Introductions ■ Changemanagement ■ Release management ■ Process and governance ■ Environment management ■ Best practice and recommendations ■ Training and communication ■ Ongoing support ■ Next steps ■ Q & A
  • 3.
  • 4.
    High Level ■ Howdo 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?
  • 5.
    Change Management ■ ChangeManagement 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
  • 6.
    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!
  • 7.
    As the platformmatured, 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
  • 8.
    Change control hasbecome 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.
  • 9.
    Why Change Managementfor 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
  • 10.
    Change Management A processof continuous evolution Vision Strategy 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.
  • 11.
    Who should beinvolved? •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.
  • 12.
    Do all changesrequire “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!
  • 13.
    Steps to EffectiveChange 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
  • 14.
  • 15.
    5 Pillars ofRelease Management 1 2 Deployment Size & New Project Cadence Evaluation 3 Environment Strategy 4 Training & Communica- tion 5 Ongoing Support Model
  • 16.
    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
  • 17.
    Release Management: ProcessFlow SFDC User SFDC Admin Change Control Board IT Submits change request Reviews request Approved? Determines release timeframe Analyzes request and timeframe IT required? Configure feature/ functionality Sandbox Environment Sandbox required? Configure feature/ functionality Production Environment Notifies CMM request completed Conducts Testing (end-user & IT) Moves changes to production environment Communicates changes to end-users User notified
  • 18.
    Configuration Changes Many Few Simple Difficult Levelof Effort Source: Faulkner 2006 Immediate Releases • Implement immediate changes • Owned by individual sub-group • Minimal impact to the production floor Minor (Monthly) Releases • Minor changes impacting two or more groups • Thrice as often as a Major Release • Minor impact to training and production Major Releases • 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 Types Does not dilute the value of force.com flexibility
  • 19.
    Release Management: Definitions ReleaseType 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
  • 20.
    ► 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
  • 21.
    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 -8 Final 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 0 Days -5 Days -8 QA Mod Test TRN INT UAT Environment Freeze ... Note: Days are suggestive
  • 22.
  • 23.
  • 24.
  • 25.
    Establish Process andGovernance • 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
  • 26.
    Governance: Focus Areas DevelopmentProcesses • 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
  • 27.
    Support Request Process:Example Above is a high-level support process. Detailed procedure for each process step needs to be developed in-house.
  • 28.
    Key role • ChangeCommittee – 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
  • 29.
  • 30.
    Considerations • How manydevelopment 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 Development Tools 7/15/14 30
  • 31.
    Real-Time Sandbox Environments FullyReplicated 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
  • 32.
    Configure, Develop, andDeploy 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 Code and Schema Metadata API Force.com Migration Tool http://wiki.developerforce.com/index.php/Migration_Tool Cloud Deploy Easy Tool for Admins to Migrate Changes
  • 33.
    Sandbox Replicates YourSalesforce.com Organization Production Salesforce.com Organization Development Sandbox: Create a separate on-demand application environment for… Training Testing (QA)
  • 34.
    Sandbox: Types, Features,Uses Features Best For… Developer • Copy of configuration/code • No data copied • 10 MB data storage • Development • Testing new features • Apex tests Configuration Only Full • Copy of configuration/code • No data copied • 500 MB data storage • Copy of configuration /code • Copy of active data and files • Same storage limits as the production organization • Testing new features • Loading standard data for regression testing • Limited use for staging/UAT • Staging / UAT • Validating new apps against active configuration and data • Testing external integrations • Training
  • 35.
    Environment Definitions Sandbox Owner (Suggested) TypePurpose 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 systemsand 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.
  • 36.
    Multi-Project Delivery Cyclewith 6 Sandboxes Production Instance Production Support Staging live full copy legend Dev Integration Long Projects configuration-only, test data configuration-only, training data developer Training Dev Dev Dev Rollup / Integration Short Projects
  • 37.
    Environment Planning Developer sandbox Configuration-only sandboxFull 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
  • 38.
    Environment Planning • Developmentenvironments 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
  • 39.
    Establish Configuration Baseline Dev Integration Testing Production Training Consolidated Dev Environment Production Org Full Sandbox 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
  • 40.
    Controlling Change • Beforemigrating 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
  • 41.
    Some Facts AboutSandboxes • 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
  • 42.
    Key roles • EnvironmentOwner – 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
  • 43.
    Establish Process andGovernance • 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?
  • 44.
    Tools: Selecting theright 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 IDE Deploy Ant Version Control
  • 45.
    Build, Test, AndDeploy From One Tool IDE Single Project View XML Application View Rich Code Editors for Visualforce and Apex code
  • 46.
    Promote Changes Seamlesslywith Change Sets BUSINESS USERS ADMINS AND DEVELOPERS PRODUCTION 1. Create Sandbox 2. Make Changes 3. Deploy Change Sets
  • 47.
    Tool Selection: ChangeSets • 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
  • 48.
  • 49.
    Tool Selection Tools ProsCons 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
  • 50.
    Continuous Integration: Example Timedbuild and release cycle for each environment Note: Need to establish release windows for each environment including production and take Salesforce maintenance window into consideration. Release Cycle
  • 51.
    Tool Selection: ChangeSet Vs Automation Change Set • 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 Continuous Integration • 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 Development 7/15/14 51 Version Control Integration UAT Production Version Control Integration Staging Production Development Metadata Metadata Code and/or Metadata Code & Metadata Code & Metadata Code & Metadata
  • 52.
    Tools Comparison Summary Need Force.comIDE 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
  • 53.
    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
  • 54.
    Sample Path toProduction Matrix Note: Table above shows a sample path to production chart. These are suggestive guidelines • 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
  • 55.
    Integration Testing Production Training Consolidated Development Full Sandbox Production Org Config-only Sandbox UAT | Pre- production EnvironmentPlan and Release Path Control 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. QA 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 Dev Dev Rollback Definition: Refresh Prior to release. IDE/change sets for rollback Change Set From Controlled environment IDE / Change set from development environment Sandbox Refresh
  • 56.
    Developer POC (Full Sandbox) QA (Full Sandbox) Eclipse Package Creation SubVersion Package Installation Testing (FullSandbox) 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
  • 57.
    Sandbox Dev QA Prod Individual Project/Dev Environments FunctionalDev Project Team 2 FunctionalDev Project Team 1 Apex and VF Dev Integration Dev Legend Deployment by Production Deployment Team Deployment by Project/Dev Team Managed by Production System Admin Sandbox 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 Sandbox Dev/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.
  • 58.
    Release Using ChangeSet • 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 Dev Consolidated Development QA Integration UAT | Pre- production Production
  • 60.
    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
  • 61.
  • 62.
    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
  • 63.
    Change Management 1. AlwaysOpen 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
  • 64.
    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
  • 65.
    Environment Planning • Dothe 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
  • 66.
    Environment Planning • Combinemultiple 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
  • 67.
    Development Practice • Uselatest 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 67 Best Practices
  • 68.
    Development Practice • CodingPractices – 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
  • 69.
    Release Management Note: Aregular refresh of all sandboxes from Production should be planned by the release manager to minimize out of sync issues.
  • 70.
    Release Management • Startwith 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.
  • 71.
    Release Management Release LeadTime • 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
  • 72.
  • 73.
    Communication Strategy • Acomprehensive 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
  • 74.
    • The technologyis 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
  • 75.
    Supplement Training withPremier Learning Paths
  • 76.
  • 77.
    Governance Functions: SupportTiers Level 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 opportunities Tier 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
  • 78.
    Ongoing Support Modelcont. • 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
  • 79.
    Next Steps • Developprocess 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
  • 80.
    Standards & BestPractices SME Knowledge & Training Materials CoE Responsibilities Reporting/Dashboard Templates 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 Responsibilities Business Requirements & Process Mapping Business-unit Specific Project Governance Basic Configuration User Training and Support CoE Participation Salesforce.com New Release Review Reporting & Measurements Business Data Validation Adherence to Best Practices User Management (Add, Delete, Update) Business Unit 2 Business Unit 3 Business Unit N Governance: Center of Excellence