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.
Best Practices for Team Development in a Single Org
Shared Development in a Single Org
The subtitle goes here
Loic Juillard, Salesforce, Director of Data Center Automation
Sriram Iyer, Salesforce, Product Management
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
Who are we?
▪ Loic Juillard
▪ TechOps Director Software Development
▪ LinkedIn: www.linkedin.com/in/Loicj
▪ Twitter: @ljuillar
▪ Email: email@example.com
One Org, Multiple teams, the dilemma
Creating multiple orgs for each environment is NOT your only solution!
Multiple Orgs vs. Single Org
• Business Process
• Reporting capabilities
• Departments / Structure
• Process Overheads
• Efficiency (Engineering
• Trust (Quality, Data Integrity)
• Agility (Velocity)
▪ Variables / Success Metrics
• Transaction volume / # of Users
• Size of Departments / Disparity in
• Strength / Experience / Maturity - Support,
▪ 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.
1. The Core Dev Team
3. Coding Guidelines
1. Release Cycle
How many standard and custom
objects total do we use in our
Salesforce serves 1.3B transactions to
our customers per day. How many do
we serve internally?
How many teams develop in our
Salesforce internal orgs?
Ingredient #1: Salesforce Development Core Team
▪ Lead: Org Czar manages the request process
▪ Team: designated SFDC developers
• Keeping the system alive
• Setting standards
• Enabling other groups to develop in org
• Deliver major capabilities
• Retiring unused applications
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?
The Core Dev Team Manages the Change
Change Review Meeting (aka. CAB,
▪ 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
▪ 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
• APEX code library used
• Class diagram
▪ Why not consider another design…?
Ingredient #3: Coding Guidelines
Your are a community, consistency is key
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
▪ Depending on the scope:
• Configuration: Direct implementation in Staging sandbox
– Create DE Org per product
– Develop in DE org
– Promote to Staging Sandbox
Setting Coding Standards
Class/ Page/ Object or any salesforce metadata API names should have prefix
Follow standards in Class/ metadata names like:
Method names should start with lowercase, Verb and follow CamelCase later.
Variable names should start with lowercase and use camel case after that. No underscores. Constants can be all capital letters with underscores.
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.
Do not use bit wise operators like & and |, instead use && and || for boolean computations.
Avoid multi level Maps/ Lists instead create data structures where applicable.
Avoid multi level for loops (3 or more levels should be avoided)
Make sure you format the apex, vf page, trigger source code properly to make it readable. Use for example: http://www.prettyprinter.de/
Do not write large methods (say more than 100 lines)
Follow basic object oriented principles like Encapsulation Encapsulation, Abstraction, Polymorphisms, Inheritance, Delegation and design patterns
like singleton, Factory etc
Every test case method should have at least one assert.
Make sure SOQL injections are avoided for security purpose
Follow case (capitalization) standards
Instead of string concatenation use String.format() to replace arguments in a template string
Check on this session chatter feed for the full document!
Proper Code Review Practices
▪ Review: Code review is mandatory, name of
reviewer is required at check-in
▪ The Development team is responsible for
code coverage, testing.
▪ The PO is accountable for proper User
▪ Analysis: E-release Root Cause Analysis are
reviewed during CAB / SMART
▪ Resolution: Issues/deviation need to be
resolved before any new release
The Release Process
Frequent + Swisswatch precision
Predictive Release Process
▪ DE org: Prototyping and early implementation
▪ Staging: Code merge and packaging
▪ Release Staging: Test the package install
▪ Integration: Merge code from other teams
▪ Production: The Holy Grail!
The Release Process
(2 weeks cadence in this case)
Acceptance: Core Team
Pilots & POCs
CAB Review (Clear)
Sync Staging Env
GUS Code review
Deploy to Near-prod
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
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
Mop-up: App lifecycle
Clean up happens as often as releases!
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
- 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
We want to hear
Please take a moment to complete our
Surveys can be found in the “My Agenda”
portion of the Dreamforce app