Best Practices for Team Development in a Single Org
4 likes4,216 views
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.
![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](https://image.slidesharecdn.com/shareddev-presentation-103113mt-131212223147-phpapp02/85/Best-Practices-for-Team-Development-in-a-Single-Org-14-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Best Practices for Team Development in a Single Org (20)
Ad
More from Salesforce Developers (20)
Ad
Recently uploaded (20)
Best Practices for Team Development in a Single Org
- 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: [email protected]
- 4. Who are we? ▪ Sriram Iyer ▪ Tech & Products, Product Management ▪ LinkedIn: www.linkedin.com/in/sriramviyer ▪ Twitter: @sriramviyer ▪ Email: [email protected]
- 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