Shared Development in a Single OrgThe subtitle goes here

Loic Juillard, Salesforce, Director of Data Center Automation@juillarSriram Iyer, Salesforce, Product Management@sriramviyer

Safe harborSafe 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 product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

Who are we?▪ Loic Juillard▪ TechOps Director Software Development▪ LinkedIn: www.linkedin.com/in/Loicj▪ Twitter: @ljuillar▪ Email: ljuillard@salesforce.com

Who are we?▪ Sriram Iyer▪ Tech & Products, Product Management▪ LinkedIn: www.linkedin.com/in/sriramviyer▪ Twitter: @sriramviyer▪ Email: sriram.iyer@salesforce.com

One Org, Multiple teams, the dilemma

Creating multiple orgs for each environment is NOT your only solution!

LJ/SI

Multiple Orgs vs. Single Org▪ Principles:

• Business Process• Departments / Structure• Culture

▪ Values:• Efficiency (Engineering

Productivity)• Trust (Quality, Data Integrity)• Agility (Velocity)

SI

▪ Trade-Offs• Reporting capabilities• Process Overheads• Credentials• Cost

▪ Variables / Success Metrics• Transaction volume / # of Users• Size of Departments / Disparity in

Processes• Strength / Experience / Maturity - Support,

Admin Processes

Risks▪ Convoluted implementation▪ Spaghetti architecture▪ Lots of dead bodies▪ Administration nightmare▪ Service disruption▪ Data loss

Lack of a well-defined process can get you a convoluted implementation of unmanageable disjointed applications.

SI

The RecipeINGREDIENTS

1. The Core Dev Team2. Requestor3. Coding Guidelines

1. Release Cycle2. Mop-up

DIRECTIONS

LJ

First, let me ask a few questions?????

LJ

How many standard and custom objects total do we use in our

internal orgs?

LJ

Salesforce serves 1.3B transactions to our customers per day. How many do

we serve internally?

LJ

How many teams develop in our Salesforce internal orgs?

LJ

Ingredient #1: Salesforce Development Core Team▪ Lead: Org Czar manages the request process▪ Team: designated SFDC developers▪ Responsibilities

• Keeping the system alive• Setting standards• Enabling other groups to develop in org• Deliver major capabilities• Retiring unused applications• Releasing

SI

Ingredient #2: The Requestor[Assess the requestor]▪ Are you the product owner?▪ Are you planning on developing in the org?▪ Talk about adoption now!

• Who will UAT?• Train?• Roll-out?

LJ

LJ

The Core Dev Team Manages the ChangeReview Meeting

▪ What is the feature?▪ What is the benefit/use case?▪ Who is/are the customer(s)?▪ Does it align with our corporate vision?▪ Do users/stakeholders agree it’s a priority?▪ How are you planning on implementing this?

• Object leveraged• Record type• Fields• APEX code library used• Class diagram

▪ Why not consider another design…?

Change Review Meeting (aka. CAB, VAT, SMART…)

▪ Who: • Integration Czar, core dev and all Pos• Architect, Lead developer orchestrating the

overall design

▪ What: Present and answer questions from all other POs on implementation

Ingredient #3: Coding Guidelines

Your are a community, consistency is key

LJ

Where does implementation happen?▪ DE Org▪ Core Dev team maintains a documented release process▪ Customers create a replicate of the org using the published release

process▪ Depending on the scope:

• Configuration: Direct implementation in Staging sandbox• Customization:

– Create DE Org per product– Develop in DE org– Promote to Staging Sandbox

LJ

Setting Coding Standards1. Class/ Page/ Object or any salesforce metadata API names should have prefix

2. Follow standards in Class/ metadata names like:

SM_<CamelCase>

SM_<CamelCase>Test

SM_<CamelCase>Trigger

3. Method names should start with lowercase, Verb and follow CamelCase later.

4. Variable names should start with lowercase and use camel case after that. No underscores. Constants can be all capital letters with underscores.

5. Make sure you have a Utility class for a major feature so all common utility methods variables are private and have public get/set methods or

create properties so can be accessed outside of the class.

6. Do not use bit wise operators like & and |, instead use && and || for boolean computations.

7. Avoid multi level Maps/ Lists instead create data structures where applicable.

8. Avoid multi level for loops (3 or more levels should be avoided)

9. Make sure you format the apex, vf page, trigger source code properly to make it readable. Use for example: http://www.prettyprinter.de/

10. Do not write large methods (say more than 100 lines)

11. Follow basic object oriented principles like Encapsulation Encapsulation, Abstraction, Polymorphisms, Inheritance, Delegation and design patterns

like singleton, Factory etc

12. Every test case method should have at least one assert.

13. Make sure SOQL injections are avoided for security purpose

14. Follow case (capitalization) standards

15. Instead of string concatenation use String.format() to replace arguments in a template string

And more…Check on this session chatter feed for the full document!

LJ

Proper Code Review Practices

▪ Review: Code review is mandatory, name of reviewer is required at check-in

▪ Test: ▪ The Development team is responsible for

code coverage, testing. ▪ The PO is accountable for proper User

Acceptance Testing▪ Analysis: E-release Root Cause Analysis are

reviewed during CAB / SMART▪ Resolution: Issues/deviation need to be

resolved before any new release

SI

The Release Process

Frequent + Swisswatch precision

SI

Predictive Release ProcessDevelopment Environments▪ DE org: Prototyping and early implementation▪ Staging: Code merge and packaging▪ Release Staging: Test the package install

process▪ Integration: Merge code from other teams▪ Production: The Holy Grail!

LJ

The Release Process(2 weeks cadence in this case)

LJ

Week –(3..n) Week 1 Week 2

Goals

Acceptance: Core Team

Environments

Functional TestRunlist TestingTraining

UATTraining

CAB Review (Clear)Design Review

Sync Staging EnvPerforce Check-inGUS Code reviewDeploy to Near-prod environment

Code Freeze

DE Org Code Staging Release StagingNear-prod

Prod

Release

2

CAB Review

RequirementsPrioritizationStakeholder Sign-ofPilots & POCsDevelopment

Integration / Jenkins▪ Dev has 3 codelines: Main, Patch and Freeze to check-in▪ The 4th branch Prod gets deployed to Production▪ When the devs check in, we have a continuous jenkins integration server that runs the

check-in through a suite of automated Apex tests and only allows the check in to go through if all the tests pass

▪ Along with Apex tests, we also have End-to-End tests running on a periodic basis using Selenium Webdriver which makes sure that none of our UI functionality is broken due to check-ins

▪ Once the Devs have completed their code check-ins for the sprint, the code is then integrated into freeze and the QE's begin testing it in the freeze org

▪ After the QE Sign off, the Release Engineer/Dev can then deploy the code changes to the Prod Branch

SI

Mop-up: App lifecycleClean up happens as often as releases!

SI

Weed-out The Old Stuff

When do you delete elements?▪ The PO and/or the team disappears and

nobody takes over▪ Utilization is minimal, far from initial plansExamples:

- Report and Dashboards utilization. Use reporting of metadata to check utilization

- Same thing for fields

• Give users a grace period (e.g. 3 months)• Hide from the Page Layout• Delete if no concerns

SI

We want to hear from YOU!

Please take a moment to complete our session survey

Surveys can be found in the “My Agenda” portion of the Dreamforce app