Issuu on Google+

On-Demand Release Management July 23, 2009


Safe Harbor Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the fiscal year ended January 31, 2009 and our other filings. These documents are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.


Agenda  On-Demand Release Management – Heather Ramsdell, Sr. Customer Success Manager

 Customer Examples

Dave Woemmel, Senior Consultant

 Overview of Services – Tony Beller, Practice Director

 Q&A


Release Management

Environment Mgmt Change Mgmt

Methodology Development Tools


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


Change Management Lifecycle 1

2

Collect ideas and requests from your “customer”

Analyze and prioritize requests

3 4 Fully-replicated

Educate your “customer”

Configure/develop and deploy using Sandbox


Step 1: Collect Ideas

Engage All Your Communities Online

Spark Conversations Around Ideas

Bubble the Best Ideas to the Top

“Increases Adoption by Making it “Mine”

Deliver on Ideas from the Community


Step 2: Analyze and Prioritize Determining what’s important  A committee should be established to review, analyze and prioritize change requests. The committee should be comprised of: –Administrators –Executive Sponsor(s) –Cross-functional business leads –IT team members  The committee should meet on a regular basis (e.g. weekly or monthly) to discuss the change requests received and review metrics such as: –Innovation Requests –Adoption/Usage/Integrity –Future Initiatives/Roadmap

Use Email to Case or Custom Object To track Activities/Requests of Admin


Change Committee Structure (example) Change ChangeCommittee Committee Program Mgr/Director Program Mgr/Director Change Mgmt Team

Functional Architect / Functional Architect / Business Analyst Business Analyst

Use Ideas for this team as a pilot for the feature

Technical Architect

Change Mgmt

BU Admins/Sponsors

Trainers Trainers

Help Desk Help Desk


Step 3: Configure/Develop and Deploy


Release Management Strategy Define a release strategy Difficult Major Releases

Minor (Monthly) Releases  Minor changes impacting two or more groups  Thrice as often as a Major Release  Minor impact to training and production

Level of Effort

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

Immediate Releases  Implement immediate changes  Owned by individual sub-group  Minimal impact to the production floor

Simple Few

Configuration Changes

Many

Source: Faulkner 2006


Step 4: Educate Your “Customer”

Hi touch One on one

Low touch Classroom

Key Best Practices:  Relevant/user focused – Custom to configuration – Job role/task based – Uses real data – On The Job support  Communities of Practice

Virtual Classroom

On Demand

Key Considerations:  Maintenance – New sales people – Additional features  Ownership of skills & knowledge transfer


Release Management Environment Mgmt Change Mgmt

Methodology Development Tools


Evolution of your Organization

Dev Sandbox

QA Sandbox

Production


Sandbox Overview 

Full Copy Sandbox –

Use Consistent Naming Conventions for Sandboxes

Full sandboxes copy your entire production organization and all of its data, including standard and custom object records, documents, and attachments

Configuration Only Sandbox –

Copy all of your production organization's reports, dashboards, price books, products, apps, and customizations under Setup, but exclude all of your organization's standard and custom object records, documents, and attachments.

Creating a configuration-only sandbox can decrease the time it takes to create or refresh a sandbox from several hours to just a few minutes, but it can only include up to 500 MB of data

Developer Sandbox –

Special configuration-only sandboxes intended for coding and testing by a single developer. They provide an environment in which changes under active development can be isolated until they are ready to be shared.

Developer Sandboxes copy all application and configuration information to the sandbox, but are limited to 10 MB of test or sample data ** Note: See Help & Training for Sandbox Considerations


Where Do I Develop? Developer sandbox

Configuration-only sandbox

Full copy sandbox

Development

 perfect, if extension app

 also fine

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

Testing

 unit tests  apex tests

 best for feature test  load standard data for regression

 best for production debugging

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

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


Release Management

Environment Mgmt Change Mgmt

Methodology Development Tools


World’s First Development Tools and Services for the Cloud Development as a Service Force.com Sandbox

Instantly Set Up Dev Environments

Metadata API

Easy Access to Code and Schema

Force.com IDE

Force.com Code Share

Everything You Need to Build Apps

Easy to Collaborate on Projects


Managing Force.com Sandbox

Refresh Sandboxes on Regular Basis and Notify Users of Refresh Setup>Manage Users>Mass Email Users


World’s First Development Tools and Services for the Cloud Development as a Service Force.com Sandbox

Instantly Set Up Dev Environments

Metadata API

Easy Access to Code and Schema

Force.com IDE

Force.com Code Share

Everything You Need to Build Apps

Easy to Collaborate on Projects


What APIs are Available? 

The force.com platform consists of 3 APIs (each play a part in development) – Data API: Leveraged to access & manipulate the data within an instance of Salesforce.com (e.g. Create Customer record) – Metadata API: Leveraged to access & manipulate the metadata within an instance of Salesforce.com (e.g. Create custom Customer object) – Apex API: API to programmatically test & compile Apex code


What is the Metadata API? 

There are 3 main ways to take advantage of the mdAPI to impact your organization’s metadata – Force.com IDE: An integrated development environment based upon the eclipse toolkit – Force.com Migration Tool: A command-line-based tool built on top of the ANT framework – Custom Tools & Applications: 3rd party applications that have been built on top of the APIs noted above

**Note: While the vast majority of components within the force.com platform and applications are supported, it is recommended that you refer to the documentation to understand what limitations may exist for your particular scope.

Create Change List Process for Unsupported Metadata Types


World’s First Development Tools and Services for the Cloud Development as a Service Force.com Sandbox

Instantly Set Up Dev Environments

Metadata API

Easy Access to Code and Schema

Force.com IDE/Migration Tools

Force.com Code Share

Everything You Need to Build Apps

Easy to Collaborate on Projects

Great Info: http://wiki.developerforce.com/index.php/Documentation


Setting up the Force.com IDE  Download & Install Java  Download & Install Eclipse  Use Eclipse, Help, Software Updates, to install Force.com plug-ins http://wiki.apexdevnet.com/index.php/Force.com_IDE_Installation_for_Eclipse_3.3.x


Force.com Migration Tool  Command-line tool for retrieval and migration  Based on Apache Ant  Use for retrieval – configure with org and list of metadata – this metadata can then be saved into version control

 Also use for migration – configure with destination org and metadata to push

 Uses same directory structure as Force.com IDE Force.com Migration Guide: http://www.salesforce.com/us/developer/docs/daas/index.html


Using Snapshot for Migration

Copies/Comparisons of Configuration can be done using Snapshot


Which Development Tool is Right? Configuration Only

APEX / Visualforce / Integrations

Manual Moves

• unsupported meta data types

Snapshot

 good use

 good for basic development (triggers)

(Developers)

 good if admin has some development background

 can use with most development tools

Migration Tool

 not good fit

 good fit if developer

(Business Admins) IDE

(IT Admins)

Testing Scripts

• good use

 Ideal for populating a test environment from version control environment  Command line tool  repeatable deployment scripts

Packaging (Partners)

Configuration Copies/Comparison

Intended Intendedfor forPartners/ISV’s Partners/ISV’s


World’s First Development Tools and Services for the Cloud Development as a Service Force.com Sandbox

Instantly Set Up Dev Environments

Metadata API

Easy Access to Code and Schema

Force.com IDE

Force.com Code Share

Everything You Need to Build Apps

Easy to Collaborate on Projects


What is Force.com Code Share 

Developer Collaboration Site – Code Repository – Promote Development on Force.com – Examples (triggers, Visual Force components, etc) – What will not be up there: • Customer intellectual property – Code to ‘optimize orders’ – Applications that provide strategic advantage

• Customer specific customizations or integrations


Now How Do I Put It Together for My Organization?


Release Management

Environment Mgmt Change Mgmt

Development Tools Methodology


Putting Best Practices Into Play

Dave Woemmel, Senior Consultant


Customer Use Case Examples > Adding New Functionality Scenario  Financial Industry customer is currently using Salesforce to manage their sales opportunities with Individuals. They have been operating using Contacts to represent Individual Consumers, but they wanted to evaluate Person Accounts.

Requirements  Configure Person Accounts without impacting current sales users  Test functionality with real customer data  Train outside of the Production Environment

Considerations  Person Accounts is an irreversible feature. Once enabled, the feature cannot be disabled.  Data Migration of SFDC Contact to Account data is complex


Customer Use Case Examples > Adding New Functionality Solution  Salesforce Consulting helped the customer set-up a full Sandbox copy of their Production org, and enabled Person Accounts within this environment to test the functionality. Once it was determined this would meet their requirements, this environment was available to perform a test conversion of Contact data, as well as train their end users. Consulting also provided the complete migration path for how to successfully update their Production org with minimal impact to end users.

Production •Source of the Sandbox, included customer data and current config

1

1. Test Full Copy Sandbox – All data from production is copied •This org was used for new feature testing and training •Environment used as final testing before moving to production

Create Person Account Record Types Create an Individual B2C Account Setup-> Customize ->Accounts -> Person Accounts -> Record Types -> New Set Existing Record Type =”Individual” Set Record Type Name = “Individual – B2C” Description = A record type of "Individual" represents a person who is or could be a client or prospect. Set Active = “Y” Set Enable for the following Profiles: Sales User – B2C Sales Manager – B2C Customer Service – B2C Click Next Set Apply one layout to all profiles and select Individual Account Layout Click Save


Customer Use Case Examples > Developing a Trigger Scenario  Insurance Customer wanted the ability to update their Prospect Accounts to Client Accounts after they successfully won an opportunity.

Requirements  Automatically update the Account record when the Opportunity stage was moved to Closed Won  Only update the Account record if it listed as type ‘Prospect’  Provide a test environment to ensure functionality works without impacting existing users

Considerations  Standard functionality did not support the customer requirement  Customer already had users managing Sales Opportunities in their Production org  Customer had a skilled developer who learned Apex  Apex cannot be directly developed in the Production UI


Customer Use Case Examples > Developing a Trigger Solution  Salesforce Consulting proposed creating an Apex trigger that would update related Account records once a user had set an Opportunity stage to ‘Closed/Won’. We helped the customer’s developer resource set-up the Force.com IDE environment to build and test the trigger, and then push it into a Full Sandbox copy for testing. Finally, we helped the customer deploy the code to Production via the Force.com IDE.

Single Single Project Project View View

XML XML Applicati Applicati on on View View

IDE

Rich Rich Code Code Editors Editors for for Visualforce and Apex Visualforce and Apex code code


Customer Use Case Examples > Managing Multiple Environments Scenario  Manufacturing Customer was considering building an integration with their backend ERP system. The IT department had strict environment guidelines for software development that included supporting multiple environments.

Requirements  Build custom integration using the Web Services API  IT required distinct Development, System Test/Stage and Production environments.  Custom components needed to be migrated to each environment without manual reconfiguration  Ability to refresh Dev/Test environments to maintain configuration with Production

Considerations  Each Salesforce environment had to align with Customer’s internal environment structure  Integration had to be tested outside of the Production org  Customer needed easy way to migrate changes from environment to environment


Customer Use Case Examples > Managing Multiple Environments Solution  Salesforce Consulting helped the customer set up a Full and Config only Sandbox to represent the Testing and Development environments. We provided a migration path and a regular refresh cycle to maintain their environments. We also reviewed the Force.com Migration tool and 3rd Party applications to migrate metadata via or metadata API.


Customer Use Case Examples > Defining Release Management Strategy Scenario  Financial Industry Customer was using a single Salesforce instance for their Marketing, Sales and Customer Service organization across multiple Business Units. Each Business Unit was requesting different sets of functionality with occasional conflicting requirements, and the company had limited admins/development team to implement changes. This made it difficult to manage business expectations.

Requirements  Single request process for new changes/requirements  Release schedule to assign features to a targeted release date  Additional environments to develop and test functionality before deploying to Production  Single place to manage all project and release information  Easy method to move configuration between environments

Considerations  Business requested a Release every 1-2 months  Request was to coincide with Salesforce product releases to take advantage of new features


Customer Use Case Examples > Defining Release Management Strategy Solution  Salesforce Consulting helped define a Release Management strategy and also implemented the Release Management on-demand application, which allowed the customer to track their projects and releases in Salesforce.

Steps 1.

Defined Responsibilities

2.

Defined Environments

3.

Defined Release Categories

4.

Implemented Release Mgmt App for tracking

5.

Established Feature Request / Issue Process


Customer Use Case Examples > Delivering Large Backlog of Requirements/Features Scenario  Healthcare Industry Customer wanted to get up and running on Salesforce in a short time frame. After gathering requirements, they realized that had a large number of requirements which could not all be delivered simultaneously, nor within the desired time frame.

Requirements  Subset of functionality needed to be up and running in 90 days  Needed easy way to prioritize requirements and have continual development  Work needed to be completed outside the Production instance.

Considerations  Customer did not have an internal tool for tracking their feature list  Short time line forced prioritization of business requirements  Customer could provide basic support for their end users without complete feature set.


Customer Use Case Examples > Delivering Large Backlog of Requirements/Features Solution  Salesforce Consulting suggested using an Agile Development methodology. This allowed the customer to enter requirements/users stories, prioritize the features, and create an ongoing iterative process that provided a workable application after 90 days, with additional requirements assigned to subsequent sprints.

Create Themes • Guiding principals captured during pre-sales cycle and/or BVA (ex – increased sales revenue)

Develop User Stories • Epic – Placeholder for further investigation • Detailed – Stories with enough information to be considered for a sprint • Prioritize user stories


Release Management Offerings

Tony Beller, Director of Consulting


Release Management Capability Some of our Release Management Capabilities are: • Sandbox environment management best practices • Change management and code deployment best practices • Establishing a Center of Excellence (COE) • Customized release management charter, process and toolset • Release Management POC Engagement Model We do not have price and details for capabilities but your SEM will tailor the engagement to meet your customer’s specific needs.


Sample Environment Management Package > Overview Applicability  Manage a single release management strategy (not concurrent) for up to 5 Sandboxes  One Org  Single language  All work performed remotely  No specific integrations or data migrations will be included in scope for the POC. Instead the team will perform a POC release cycle with a sample code snippet.

Deliverables  Release Management on-demand application  POC release cycle (move Visualforce, Apex trigger snippet from dev -> test -> prod)

Prerequisites  Familiarity with Eclipse and application lifecycle management  Knowledge of Force.com standard objects  Understanding of data modeling and user interface development principles


Sample Environment Management Package > Timeline Day

Description

Deliverable

1

• Review Engagement Scope, Schedule and Goals

Kickoff

• Foundation Work (Salesforce terminology, best practices, available tools, end-to-end release management process – task, activities, participants and deliverables)

Best Practices Workshop Requirements Session

• Discovery of Current State (what’s working/not working today) 2

Track Breakouts for To-Be Process

Requirements Session

• Functional Deep Dive (with business owners) •

Implementing the Success Factors

Release Management Process Details

Hands-on work with Release Management on-demand application

• Technical Deep Dive (with technical owners) •

Knowledge Sharing on Advanced Migration Topics

POC Inputs (what toolset, what code base to demonstrate?)

Hands-on training of migration tools

3

Building POC

Configured POC

4

POC Presentation

Training

• Hands-on demo of a proposed release cycle with toolset. Team will demo on a new request is captured, work and promoted in the Salesforce environment. Wrap-Up Meeting (Next Steps)


Sample Environment Management Package > Key Tasks Pre-work: 

Consultant – Prepare questionnaire

Customer & Consultant PM – Organize engagement logistics (Schedule meetings, define audience, coordinate questionnaire)

Customer – Populate and return questionnaire

During Engagement: 

Kickoff Meeting (joint session)

Best Practice Workshop (joint session)

Release Management Deep-Dive (PM working with business audience)

Environment Management/Migration Process Deep Dive (TA working with technical audience)

Build Release Management on-demand application

Develop Technical Migration POC

Presentation of Release Cycle POC


Sample Environment Management Package > Topics Covered during Day 2 Break-Out Sessions Functional Track

Technical Track

Implementing Success Factors • Leadership • Defined Schedule • Proactively Mitigate Risk • Accountability • Address Current Pain Points

Implementing Success Factors • Available migration tools (ANT, Eclipse) • Standards (naming conventions, rollback strategy, sandbox refresh) • Configuration migration options • Aligning environment setup with migration strategy

Release Management Application workshop • Demonstrate end-to-end process • Customize for project and/or customer’s needs

Development as a Service (DaaS) • Force.com IDE for configuration migration • Code Sharing techniques • Manage multi-team and multi-project development initiatives with Force.com • Analyze usage of Sandbox environments in development projects

Where To Go From Here? • Courses • Resources

Visualforce Pages • Find out when to move to Apex for creating custom controllers or extensions Apex • Use testing, debugging, and deploying controllers capabilities • Learn the basics of testing controllers vs. regular Apex Where To Go From Here? • Courses • Resources


On Demand Tool Set PM Toolkit • Centralized, online, collaborative solution tool for: – Project Planning – Document Sharing – Release Management – Status Reporting – Requirements Planning

Agile Scrumforce Methodology • Easy to manage product backlog providing simple drag and drop prioritization • Full visibility into sprint progress with Burndown charts, story and task remaining work, and team allocation • Easy task management and creation for your User Stories and Sprint Planning • Virtual Scrum Wall with graphical presentation of story and task cards for distributed teams • Simple reporting and dashboards for Enterprise wide visibility into team and release progress


Thank you!

Q&A

Thanks!


Appendix  Where to Learn More  Sandbox Considerations  Supported Metadata Types


Where to Learn More  Always visit the sandbox solution or blog post for details! – Solution: “Sandbox Solution Upgrade Window” – Blog Post: just search for “Sandbox Upgrade” on community


Where to Learn More  Webinar Recording: – http://salesforce.acrobat.com/p81248475/

 To get a free Developer Edition instance – http://developer.force.com/

 Force.com IDE – http://wiki.apexdevnet.com/index.php/Force.com_IDE

 Force.com Migration Tool – http://wiki.apexdevnet.com/index.php/Migration_Tool_Guide

 Metadata API, see API Developer’s Guide – http://wiki.apexdevnet.com/index.php/API#API


Sandbox Considerations 

Customizations and data changes in your production organization do not automatically appear in your sandboxes. You must create a new sandbox or refresh an existing one to see the customizations made to your organization since the last time you created or refreshed a sandbox

Sandbox copy is a long-running operation that occurs in the background. You are notified of the completion of a sandbox copy via email. Sandbox refreshes may complete in minutes, days, or even more than a week

Always log in to your sandbox organization using the https://test.salesforce.com login URL

Sandbox IDs can change with each refresh

Salesforce stores sandbox organizations on several instances. When a sandbox is created or refreshed, an instance is selected for your sandbox, so your sandbox may appear on different instances and have different URLs


Sandbox Considerations 

When data that contains object IDs is copied from your production instance into your sandbox, the object IDs in your sandbox match the object IDs in your production instance

Sandboxes must be on the same version as Production in order to take advantage of the AppExchange

Freeze all changes to your production organization while a sandbox is being created or refreshed. Setup and data changes to your production organization during the sandbox creation and refresh operations may result in inconsistencies in your sandbox.

Refreshing a sandbox deletes and recreates the sandbox as a new copy of the production organization. In effect, this reverses any manual access changes you have performed. If you created users on sandbox, they will no longer exist; if you changed a user’s profile and permissions, those will revert to their values in the production organization. This means that after a refresh, any access changes you performed must be repeated in the new copy. To avoid this process, you can create user templates in your production organization, and then activate them in the sandbox organization.


Sandbox Considerations Features Disabled in Sandbox  Case escalation, opportunity reminders, and contract expiration warnings are disabled because they automatically send email to contacts, customers and users who should not interact with sandboxes.  Subscription summary  Automated weekly data exports  The ability to create Salesforce sandboxes.  Testing Salesforce Content in your sandbox is not supported.  Testing Salesforce for Google AdWords in your sandbox is not supported. Attempting to test Salesforce for Google AdWords in your sandbox will result in errors because your sandbox organization operates with the same link to your Google AdWords account as your production organization.  Email service addresses that you create in your sandbox cannot be copied to your production organization. ** Note: These features can not be enabled in the sandbox


Sandbox Considerations Info and URLs 

Links – Avoid using absolute URLs in custom links https://na1.salesforce.com/00Oz0000000EVpU&pv0={!Account_ID} – Instead use relative URLs /00Oz0000000EVpU&pv0={!Account_ID} – only use relative URLs in your production organization

Integrations – Do not hard code integrations toward a specific instance. • Web Service API calls

Sandbox and production instances upgrade at different times – A Sandbox may be upgraded earlier or later than the production org, depending on instance – Sandbox instance is determined by date of the copy – Look at trust.salesforce.com for information on sandbox upgrade timing


Metadata API ♌ Type/Feature Support Rename Tab and Field

Custom field

Workflow Rules

Custom object

Workflow Alerts

Apex class

Workflow Action

Apex trigger

Workflow field updates

sControl

Workflow messages

Custom app

Workflow tasks

Custom tab

Workflow process

Visualforce page

Page Layout

Profile

Page Layout assignments

Assignment rule

Documents / Folders

Home page layout

Escalation rule

Package

Home page component

Big deal alerts

Record Type

Custom web page links

Console setup

Field level security

Validation rule

Queue

Translation workbench Report Custom report type Dashboard Approval Process Button override List view (custom objects) Field dependency

Picklist / Rec Type map

User

Custom buttons / links

Role

Email template

Sharing model

Static Resource Letterhead

Mail merge template Email to case Public Knowledgebase Self Service Portal settings


Everything to Know About Release Management