Are your business partners asking to be able to create their own applications? Are you asked to share development environments with other teams? Join us to learn considerations and best practices for making shared development in a single org a success. We'll cover process management, development methodology, release processes, and apps life cycle maintenance.

1. Shared Development in a Single Org
The subtitle goes here
Loic Juillard, Salesforce, Director of Data Center Automation
@juillar
Sriram Iyer, Salesforce, Product Management
@sriramviyer

2. 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 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.

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

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

5. One Org, Multiple teams, the dilemma
Creating multiple orgs for each environment is NOT your only solution!
LJ/SI

6. Multiple Orgs vs. Single Org
▪ Principles:
▪ Trade-Offs
• Business Process
• Reporting capabilities
• Departments / Structure
• Process Overheads
• Culture
• Credentials
▪ Values:
• Efficiency (Engineering
Productivity)
• Trust (Quality, Data Integrity)
• Agility (Velocity)
• Cost
▪ Variables / Success Metrics
• Transaction volume / # of Users
• Size of Departments / Disparity in
Processes
• Strength / Experience / Maturity - Support,
Admin Processes
SI

7. 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

8. The Recipe
INGREDIENTS
1. The Core Dev Team
2. Requestor
3. Coding Guidelines
DIRECTIONS
1. Release Cycle
2. Mop-up
LJ

9. First, let me ask a few questions
?????
LJ

10. How many standard and custom
objects total do we use in our
internal orgs?
LJ

11. Salesforce serves 1.3B transactions to
our customers per day. How many do
we serve internally?
LJ

12. How many teams develop in our
Salesforce internal orgs?
LJ

13. 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

14. 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

15. The Core Dev Team Manages the Change
Review Meeting
Change Review Meeting (aka. CAB,
VAT, SMART…)
▪ Who:
▪ What is the feature?
▪ What is the benefit/use case?
▪ Who is/are the customer(s)?
• Integration Czar, core dev and all Pos
▪ Does it align with our corporate vision?
• Architect, Lead developer orchestrating the
overall design
▪ Do users/stakeholders agree it’s a priority?
▪ What: Present and answer questions
from all other POs on implementation
▪ How are you planning on implementing this?
• Object leveraged
• Record type
• Fields
• APEX code library used
• Class diagram
▪ Why not consider another design…?
LJ

16. Ingredient #3: Coding Guidelines
Your are a community, consistency is key
LJ

17. 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

18. Setting Coding Standards
1.
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

19. 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

20. The Release Process
Frequent + Swisswatch precision
SI

21. Predictive Release Process
Development 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

22. The Release Process
(2 weeks cadence in this case)
Week –(3..n)
Week 1
Week 2
2
Release
Goals
Acceptance: Core Team
Environments
Requirements
Prioritization
Stakeholder Sign-of
Pilots & POCs
Development
CAB Review
DE Org
Functional Test
Runlist Testing
Training
CAB Review (Clear)
Design Review
Code Staging
UAT
Training
Sync Staging Env
Perforce Check-in
GUS Code review
Deploy to Near-prod
environment
Release Staging
Near-prod
Code Freeze
Prod
LJ

23. 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

24. Mop-up: App lifecycle
Clean up happens as often as releases!
SI

25. 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 plans
Examples:
- 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

27. 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