Development Best Practices
9 likes4,858 views
The document provides best practices for development, testing, and release management on the Salesforce platform. It recommends establishing a center of excellence to manage governance, using agile methodologies like Scrum for development, and maintaining separate environments for each stage of the development lifecycle. Testing strategies should incorporate unit, integration, user acceptance, and regression testing. Release management should be handled by a dedicated release manager who follows a release roadmap and ensures changes are tested and approved before deployment to production. Automating deployments, implementing source control, and refreshing sandboxes regularly are also advised.
Development Best Practices
- 1. Development Best Practice's James Burns Senior Director and Solution Architect, Customer Success Office of CTO [email protected]
- 2. Forward-Looking Statements 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. Key Elements of a Salesforce Governance Framework Center of Excellence (CoE) The process of managing governance. Change Management The process of managing the overall program or project lifecycle — from collecting business requirements to moving code from development through production. Org Strategy The design and structure of the foundational “orgs” or areas where the customer’s Salesforce applications will reside and run. Technical Governance The guiding principles for effectively developing the technical aspects of Salesforce. Center of Excellence Change Management Org Strategy Technical Governance
- 4. The Software Development Lifecycle: Salesforce Stages Test Ideas Maintenance Implement Design
- 6. The Traditional Development Process Traditional systems often create a traditional cadence Source Control System Developer Community Production Systems Functional Testing Integration Testing Business Testing
- 7. Salesforce Way Backlog Release Management Development Process Ideas Business Backlog Sprint Developers • Code or Configure • Unit Test • Migration Scripts Testing User Acceptance Testing Production Environmental Management Agile Methodology Break-Fix
- 8. Recommended Development Methodology: Agile Daily 2–4 Weeks No Duration Changes Input From Customer Sprint Planning Meeting TrainingArchitectSprint Backlog Business Backlog Review
- 9. Environmental Management Allow multiple teams to develop new capabilities
- 10. What Can You Change in Production? Customers often ask, "What can we change directly into production?” Generally, “nothing” is the answer, but there are exceptions. Examples of tasks that can happen in production: • Administration tasks such as single sign-on (SSO) certifications • Minimal risk administration changes in production: • Templates: email, dashboards, reports • User management • Knowledge management • Other changes (these should follow a decision tree) Note: Sync any changes made in production with a source control system.
- 11. Decision Tree Requirement Does it affect another application? Does it affect another process? Does it involve a data change? Does it involve a UI change? Implement with a test plan and update the source control. Yes No Yes No Yes No Yes No IMPACT Analysis No Yes Add to the backlog and roadmap. Make sure all Stakeholder are considered Yes
- 12. Release Strategy: Options Few Major Releases Salesforce Releases Break-Fix Minor Releases Enhancements Many SimpleEffortLevelDifficult
- 13. Sample Environment Architecture: Major (1) 1. Developer: In this sandbox, multiple people work together on the same use case. In this example, they share the same developer sandbox. Often, a mixed team of experienced and novice developers work together, which fosters a transfer of skills. The experienced developers can help with the creation of ANT scripts. 2. Developer: In this case, there is a one-to-one ratio between developers and sandboxes. 3. Developer Initial QA: This sandbox is where the QA team has started to build their QA test scripts; this work can be started within a Developer sandbox. 4. Developer Pro QA: When all the user stories for a sprint are completed, all the code and configuration merge together so the QA team can ramp up their testing. In this case, the volume of test data is normally greater, so a Developer Pro sandbox is the best selection. Developer Developer Developer Initial QA Developer Pro QA Full Break-Fix Full Training Full Performance Testing UAT Partial Integration Testing 9 1 2 38 4 56 7 Production Source Control
- 14. Sample Environment Architecture: Major (2) 5. Partial Integration Testing: Most Salesforce solutions involve integration to other systems; to perform this testing, sample of production data is normally required. We recommend a Partial Data sandbox. 6. Full Performance Testing UAT: To complete UAT, you need a complete copy of production data. 7. Full Training: Before you update the production system, you need to offer training to users: a Full sandbox is the best experience for this scenario. 8. Full Break-Fix: As customers begin using Salesforce for business-critical systems, you need to test all changes in production. Since human errors occur, a break-fix process (which is independent of a release roadmap) is required. To support this process, a you need a Full sandbox that is independent of the release roadmap. 9. Production: This is a current production instance. Developer Developer Developer Initial QA Developer Pro QA Full Break-Fix Full Training Full Performance Testing UAT Partial Integration Testing 9 1 2 38 4 56 7 Production Source Control
- 15. Development Best Practices Good development starts with design
- 16. Development The Salesforce platform is based on the Model-View-Controller (MVC) architectural pattern: Controller Application logic Model Objects (standard, custom, and external) View User interface (web client and the Salesforce1 Mobile App)
- 17. A Solid Architecture Starts With These Design Principles • Build a data model. • Put configuration first. • Ensure the 80–20 rule. • Create personas. • Keep it simple. Remember: The overall process is to design, develop (configuration and code), and test.
- 18. Design Challenge and Considerations Challenge Your team lacks understanding of the scope of the configuration capabilities. Considerations • The developers for your project: • What is their background? • Do they jump into code? • What is their mindset for writing code? • Code review: Determine if it can be replaced by configuration. • Design: Ensure sufficient time for designing the system during sprint planning. • The 80–20 rule: Go fast and iterate. • Over configuration: Use a small amount of code (sometimes it improves the overall maintainability of the system). • Available components (within AppExchange): Use the “buy or build” strategy. • Strategic planning: Use a Salesforce roadmap to benefit your project. • Long-term maintainability: Make the design cost effective. Visual Development – When to Click Instead of Write Code
- 19. Configuration or Coding? Configuration Coding Challenges • Build a data model. • User interface • Reporting • Business logic: • Formulas • Validation rules • Workflows Advantages • Scalable • Maintainable • Fast • You don’t need to be a programmer. Disadvantages • Fixed UI • Can get complex. • Advanced business logic • Testing • Triggers • Controllers • Classes • Custom UI Advantages • Flexibility • Strong versioning • Can be reused. Disadvantages • Can get complex. • Technical debt • Testing • Skill sets: • Business analysts and professionals • Programmers • A custom UI may require Apex code. • Time to market • Declarative testing • Complex systems – declarative • Security • Large data volumes Best Practices Tips: • Push declarative testing to the limit. • Remember: “80 percent is good enough.”
- 20. Testing Strategy Learn how to set up effective testing
- 21. The Testing Cycle Development User Acceptance Testing Production Release Manager Perform Unit Tests Evaluate Outcomes Refactor or Push to QA Write Code Quality Assurance Functional Test Regression Test Automated Smoke Test End-to-End Performance TestApproved Failed
- 22. What’s Required? Component or System- Level Testing User Acceptance End-to-End Environments Testing Performance Tools
- 23. The Salesforce Testing Strategy Component Functional Client Integration and Performance End-to-End Regression Code and Configuration When Should I Do It Tools Types Testing Why It’s Important Roles and Responsibilities Types
- 24. Release Management Let’s look at how software is managed between environments
- 25. The Effects of Poor Release Management The consequences of a poorly managed software release or environment include: • Too many sandboxes. • Lack of ownership. • No clear path to production (change set, ANT, managed package, or manual). • Low-quality coding and testing. • Conflicting release calendars. • Frequent conflicts with code and configuration. • Unclear system integration maps. • No planned refresh schedule. • Developers, testers, and release engineers under constant stress. • Unsuccessful deployments. • Changes made directly in production. • Overall low quality and adoption.
- 26. Our Recommendations People Tooling Benefits • A release manager who is independent of development and QA should perform the release. • The Business owner should approve any changes in the production environment. • Remember: Separation of duties (as recommended by ITIL). • For most projects — except for very small ones — you’ll need additional software tools to manage source control and automated builds. • These tools are generally inexpensive or free to purchase. • However, they will need to be hosted either on an on-site server or on a cloud service. • Faster, more reliable deployments • More innovation in less time • Higher user adoption • Better ROI • Less IT operations risk
- 27. The Path Forward How to achieve your long-term goal What can you achieve with better software release and environment management? • Clearly define your release environments. • Define and enforce duties. • Assign owners to sandboxes and deployments. • Automate testing and deployment. • Unify and publish a release calendar. • Introduce the concept of release waves. • Reduce the number of off-cycle releases. • Communicate everything. • Improve quality and enhance adoption.
- 28. Metadata API Metadata API is designed to retrieve, deploy, create, update, and delete customization information for your organization XML Standard Objects XML Custom Objects XML Report XML Workflow Rules XML Apex Classes XML Apex Trigger XML Visualforce Pages METADATA API (Web Service Description Language) Source Code Repository
- 29. Code Migration: Best Practices At the start of the day, perform these tasks: • Refresh your sandbox and get the source control system to push the metadata to the new org. • Remember: By refreshing the sandbox, you will lose all the original code and configuration. • Ensure that migration scripts are correct by testing prior to moving to a sandbox. • Verify that: • Your previous day’s work has been presented. • Your enhancements have not been broken by other developers’ enhancements (run your test scripts again). Keep in mind the following: • An automated script will not impact productivity, but it will enhance quality. • This process is not only testing the enhancements — it’s also testing the migration process.
- 30. Tool Best For Limitations Change Sets • Sandbox to production migrations • Change management without source control • Auditing previously deployed changes • Enforcing code migration paths • Deploying the same components to multiple orgs • Small implementation • You can only move metadata between a production or and its sandboxes. • You can't delete components. • There is no support for source control. Eclipse IDE • Project-based development • Deployment to any org • Synchronizing changes • Some setup is required. • It’s not always upgraded at the same time as other Salesforce products. • It has repeatable deployments that require re-selecting components, which can be time consuming and can introduce errors. Force.com Ant Migration Toolkit • Scripted and scheduled deployments • Repetitive tasks using the same set of components • It requires a more developer-oriented skill set (familiarity with Ant, scripting tools, and CLI). • It requires storing a username and password on a disk, which may be against your security policies. Summary of Migration Tools
- 31. Tool Best For Limitations Force.com Workbench • Ad hoc queries • Metadata describes • Lightweight data loads • It’s not an officially supported product. • It does not have project management features. Force.com Command- Line Interface (CLI) • Passwords prohibited from being stored on disk due to security polices • Required interactive login • Scripting and automated tasks Logging in may be difficult behind a firewall. Unmanaged Packages • One-time setup of a development environment • A starting point configuration that is customizable You can't make further changes to packaged components using subsequent packages. Managed Packages • Commercial applications • You want to add to multiple orgs, possibly non-related orgs • Access to code is limited or hidden. • Unique namespace can be bothersome or a blocker. • Difficult to modify or delete components. Summary of Migration Tools
- 32. Source Control: Best Practices Commit early and often: Commits should be small and should work together. Push code to the system at least daily. Accompany every commit with a short description of what is being committed. Code should be assigned to one of at least four branches: Trunk, development, integration, and break-fix. Additional R&D branches can be created simply for trying ideas. Make sure releases to QA and production are tagged centrally. • Tag release 1.0 as Production_Release_1.0. • Tags are never modified after they are created. Don’t push code that does not build or pass unit tests. Do push code that builds, but may not be perfect yet.
- 33. Release Manager: Best Practices (1) Avoid making changes directly into production. Refresh all sandboxes as soon as possible after a release has been pushed to production. Refresh can take time if you have large data volumes (LDV). Ensure that all migrations are automated. Ensure all migration scripts are tested. Avoid use of change sets. Script unsupported metadata (if you are using) to the automated process. Complete regression testing before coding is pushed to production. Ensure that developers create a unit test for all code and configuration. Aim for 95 percent code coverage of Apex code. Consider using the Quick Deploy feature to find issues quicker.
- 34. Release Manager: Best Practices (2) Make sure you have a well-documented release roadmap. Avoid any delay in the planned release date. • Capability is failing to meet the definition of done. • Capability is cut and added to the backlog. Ensure that applications within the same org follow the defined release schedule. Plan a regression test cycle on a pre-release sandbox before a Salesforce release. Ensure that business users complete UAT and use the system as they would in their daily work. The users should not follow a predefined script. Put a comprehensive communication plan in place for the release. Develop a training plan and create content before the release. Note: A release manager who is independent of any Scrum team should manage the release process.
- 35. Release Manager: Roles and Responsibilities Accountable Responsibilities Interfaces With • Manage all aspects of the end-to-end release process. • Sign off the release for implementation. • Coordinate Scrum, UAT, and third-party teams. • Ensure teams follow the company's established policies and procedures. • Follow the service release and deployment policy and planning. • Ensure all data migration has been completed successfully. • Document outstanding known errors and workarounds. • Release documentation, communications, and training. • Implement a source control system. • Provide a release roadmap. • Conduct service roll-out planning. • Manage reports on release progress and service-level agreements (SLAs). • Ensure release acceptance, including Business sign-off of UAT. • Security management • Test management • Adoption management • Training management • Communication management • Support management
- 38. thank y u