Recommended
Recommended
More Related Content
Similar to IT SIMPLY WORKS! … UNTIL IT BREAKS. STANDARDS, BEST PRACTICE AND ENTERPRISE PATTERNS FOR DECLARATIVE SOFTWARE DEVELOPMENT (Tahoe dreamin 2018)
Similar to IT SIMPLY WORKS! … UNTIL IT BREAKS. STANDARDS, BEST PRACTICE AND ENTERPRISE PATTERNS FOR DECLARATIVE SOFTWARE DEVELOPMENT (Tahoe dreamin 2018) (20)
More from Daniel Stange
More from Daniel Stange (6)
Recently uploaded
Recently uploaded (20)
IT SIMPLY WORKS! … UNTIL IT BREAKS. STANDARDS, BEST PRACTICE AND ENTERPRISE PATTERNS FOR DECLARATIVE SOFTWARE DEVELOPMENT (Tahoe dreamin 2018)
- 1. #tahoedreamin It simply works... until it breaks
- 2. #tahoedreamin Daniel Stange Technical Architect die.interaktiven | Salesforce User Groups Found Salesforce boring in the dark ages - Changed my mind. Frankfurt, Germany User Group Lead You can find me at @stangomat Meighan Brodkey Technical Architect SR Consulting | Salesforce User Groups 10 years in the ecosystem, from admin to architect. Love the platform and giving back to the the Ohana. Seattle WIT User Group Leader. You can find me at @MeighanSF
- 3. #tahoedreamin To build awesome and robust point & click solutions, you need to think and work in patterns Salesforce developers should know by heart.
- 4. #tahoedreamin And we don‘t mean common Salesforce developer patterns...
- 5. #tahoedreamin Reminder: SOME Salesforce devs... Do documentation /* * 2012 by Daniel * TODO: docs */ Build for scale for (Account a : accs) { update a; } Build unit tests @isTest ... i++; i++; Use inline comments //doing some magic here
- 6. #tahoedreamin Every developer can do better... Including you, no-code jedi!
- 7. #tahoedreamin Agenda You can be a better developer without having to be a developer at all: ◇ Think and work in enterprise development patterns (...just without the code) ◇ Design ◇ Build ◇ Test ◇ Deploy
- 8. #tahoedreamin Great Patterns ◇ Change Management ◇ Documentation ◇ Consistency ◇ Simplicity ◇ Scalability ◇ Test-Driven
- 9. #tahoedreamin Change Management ◇ Restrict changes in productive org to Reports, Dashboard and List views ◇ Establish one user who authorizes the migration of any change to production ◇ Establish a consistent workflow to migrate your metadata ◇ Establish a consistent way to model data for your project
- 10. #tahoedreamin Documentation ◇ Knowledge about your org and changes has to be stored where it is accessible ◇ Index of objects and logic should be the minimum ◇ Aim big: Create full business process and implementation logic for new stuff and add old stuff whenever you touch it Little Helpers ◇ Elements Cloud (freemium) ◇ Config Workbook (app exchange) ◇ Wiki & Issue Trackers (e.g. Jira/Confluence)
- 11. #tahoedreamin Consistency ◇ Naming Conventions ◇ Data Modeling ◇ Layouts ◇ Establish Paradigms that your users can learn and recognize
- 12. #tahoedreamin Simplicity ◇ Choose simple and performant solutions ◇ Prefer accessible solutions ◇ Avoid monoliths - break down complex logic
- 13. #tahoedreamin Scalability ◇ Any logic has to work if you change one record, but also for millions of records or thousands of users at the same time
- 14. #tahoedreamin Test-Driven ◇ Model your solutions to solve test cases ◇ Model your testing to stress every aspect of your solution ◇ Try to break your solution to smaller, testable parts and keep notes on how to test them, incl. expected outcomes Little Helpers: ◇ Metadata tools like Copado or Gearset offer test execution schedules and change monitoring (partly even in free plans)
- 16. #tahoedreamin Start with documentation ◇ User Story Pattern: “As <Person> I need <Functionality> to <Problem to be solved>” ◇ Acceptance Criteria ◇ Add a solution design and/or flow chart, entity-relationship diagrams etc. Little Helpers: Agile Accelerator (AppExchange) Issue Trackers (e.g. Jira) Copado Change Management (AppExchange) elements.cloud / gliffy / LucidCharts
- 17. #tahoedreamin Inspect existing logic ◇ Make sure you understand any logic that already exists for the relevant objects ◇ Document your findings, if no docs are available yet ◇ Consider modularizing and/or extending existing logic
- 18. #tahoedreamin Choose your toolset ◇ If possible, stick to one automation tool per object ◇ If possible, use one master process per object and “handlers” to extend the master process ◇ Don’t be afraid of Flows ◇ … but try to use the most simple tool to solve a problem Visit David Liu‘s session today: Clicks vs Code – which one should you choose? 5:10 pm, Sand Harbor II
- 19. #tahoedreamin Caution when mixing automation tools. (Apex often adds an explosive component) Hidden gem: Perspectives in the Developer Console allow you to inspect the execution of your logic.
- 20. #tahoedreamin Plan for Scale Make sure everything can handle at least 200 records at a time.
- 21. #tahoedreamin Be specific Use specific Entry Conditions for Automations to reduce workload and “false positives”
- 22. #tahoedreamin No Apex, No Limits? Declarative tools consume governor limits and are subject to platform restrictions
- 23. #tahoedreamin Shared ressources Whenever one or more records are created, updated, deleted, undeleted ◇ all logic shares limits in a single context (except managed packages) ◇ 50,000 records can be loaded in 100 operations ◇ 10,000 records can be changed in the database in 150 operation ◇ if more than one record is sent to the database, up to 200 records are handled at the same time ◇ you cannot edit System data (e.g. Users) and regular data (e.g. Opportunities) in the same context (“mixed DML”)
- 25. #tahoedreamin You need a sandbox NO EXCUSES
- 26. #tahoedreamin
- 27. #tahoedreamin Development Lifecycle ◇ Create development environments. ◇ Develop using Salesforce Web and local tools. ◇ Create testing environments, including UAT and integration. ◇ Migrate changes from development environment to integration environment. ◇ Test. ◇ Migrate changes from integration environment to UAT environment. ◇ Perform user-acceptance tests. ◇ Migrate changes from UAT environment to staging environment. ◇ Replicate production changes in staging environment. ◇ Schedule the release.
- 28. #tahoedreamin Before you start ◇ Run all local unit tests to verify that your development environment is clean. In case of failures: ◇ Take notes of what failed and why ◇ Address the resolution of all failing tests with the client / developers / your team
- 29. #tahoedreamin Execution Order ◇ Triggers run before almost all declarative tools ◇ Workflows fire triggers once again (and just once) ◇ Processes and flows run almost at the end of the operation (but can and will fire triggers, again ◇ Emails sending happens after finally committing the record to the database ◇ Time based logic will re-evaluated at the time of execution
- 30. #tahoedreamin Using entry criteria Entry criteria ◇ should filter and reduce so that logic is only executed for relevant record ◇ validate all required data Some friends to remember ◇ ISCHANGED(), PRIORVALUE() functions ◇ “changed to subsequently meet criteria” setting for workflow rules ◇ recursive execution option for process builder
- 31. #tahoedreamin Using null checks ◇ absolutely required if you are using data from related records ◇ always check use ISBLANK() or ISNULL() before your access a related record) and to avoid unintended copying of blank values
- 32. #tahoedreamin Opportunity Using related records Account SOQL Query Opportunity Line Items SOQL Query DML
- 33. #tahoedreamin Using related records ◇ Pulling in data from relating records in process builder consumes 1 SOQL query and SOQL rows ◇ Updating related records consumes 1 DML statement and DML rows ◇ Updating related records fires triggers and declarative logic on the related object - the context is getting bigger ◇ Flow and process builder are “bulkified by design”, but you have to help
- 34. #tahoedreamin Using no-code futures A “future” call is simple way to tell code: Do that later outside of my current context. ◇ own resources & limit ◇ but no context of the current operation (e.g. PRIORVALUE() / Trigger.old) If you invoke a process or flow from process builder, that essential works like a future call (just without code)
- 35. #tahoedreamin The record couldn‘t be saved because it failed to trigger a flow. A flow trigger failed to execute the flow with version ID 301b0000000g2s6. When it breaks...
- 36. #tahoedreamin An error occurred at element myRule_4_A2 (FlowRecordUpdate). Too many SOQL queries: 101
- 37. #tahoedreamin When it breaks... ◇ Browser extensions like Salesforce Inspector help you find the flow by Id ◇ Developer Console “Analysis Perspective” helps you inspect the logic and shows limit consumption
- 38. #tahoedreamin Debugging for No-Coders ◇ Read all messages carefully to identify IDs, component names and possible error reasons. ◇ Use chatter, email, or platform events to publish steps into groups / emails / channels, or to the record’s feed ◇ Use the fault handler in Flow
- 41. #tahoedreamin There‘s stuff to do ◇ Documentation. It‘s part of building. Seriously. ◇ Test it And by testing, we mean testing. Thorough testing. ◇ Review it In pairs or teams. You can‘t review your own work. Seriously (again) ◇ Deploy now you can, young padawan.
- 42. #tahoedreamin Documentation ◇ Overall rationale of the development ◇ Flow charts / Description of the logic ◇ Components Did you think of ◇ Deployment Steps ◇ Consistently name all components ◇ Consistently fill description fields ◇ Add meaningful help texts
- 44. #tahoedreamin Manual Testing Run tests Apex Unit Tests Bulk Test
- 45. #tahoedreamin Manual Testing ◇ Does the logic work as described? ◇ Are all acceptance criteria satisfied? ◇ Does the logic affect you when you’re doing unrelated things? ◇ Can you create conditions that cause your logic to break? ◇ Test bad data, missing data, entry criteria too (negative testing patterns)
- 46. #tahoedreamin Apex Unit Test ◇ Run all local unit tests to verify that all tests still complete ◇ Did you break something
- 47. #tahoedreamin Bulk Testing ◇ Keep (or create) CSV files for meaningful bulk tests ◇ Test all database operations (insert, update, delete, undelete) ◇ Test
- 48. #tahoedreamin User Acceptance Tests ◇ Let key users test drive your development ◇ Ask them do routine work ◇ Ask them to solve the problem they were thinking of when giving their “user stories”
- 50. #tahoedreamin Towards Deployment ◇ Make and communicate a release plan ◇ Train your users ◇ Prepare your deployment (Documentation & Bundle) ◇ Backup Data ◇ Create a fresh Sandbox as a Metadata Backup ◇ Dry run (if needed)
- 51. #tahoedreamin Release Planning ◇ Use off-peak hours and days ◇ Communication is key ◇ No surprises ◇ Allow people ◇ No pre-weekend, pre-holidays, last-hour-of-the-day exercises
- 52. #tahoedreamin Training ◇ Realistic scenarios that users can relate to - in a sandbox ◇ Consider pre-built datasets and ETL or using DX to create environments ◇ Again: Documentation and Communication is key ◇ Chatter group & Files / Libraries for end user documentation and training (recorded sessions, manuals, cheat sheets etc.)
- 53. #tahoedreamin Deployment Documentation ◇ Step-Number and/or Order of Steps ◇ Manual PRE-deployment tasks ◇ Deployment tasks ◇ Components (Metadata Type, Object, Name/Label, API-Name) ◇ Manual POST-deployment tasks
- 54. #tahoedreamin Backup ◇ Create a fresh Sandbox off Production as a metadata backup ◇ Use your favorite ETL tool for a data backup ◇ Prepare your deployment bundle in the backup sandbox to overwrite your changes in case you need to roll back your changes (“negative changeset strategy”)
- 55. #tahoedreamin Dry Run ◇ Create a fresh Sandbox off Production as a dummy target ◇ Send your changeset and walk through your deployment document
- 56. #tahoedreamin Deploy ◇ There are limits to Metadata types that can be deployed ◇ Changeset deployments through a deployment path are tedious and prone to errors like missing components etc. ◇ Browser extensions can support the process ◇ Metadata API is the preferable way ◇ Lots of free tools (DX and Ant Tool) and paid ones (Gearset, AutoRabit, Flosum, Copado)
- 57. #tahoedreamin Finishing Up ◇ If you had processes and flows in your deployment, make sure they are activated (these components are deployed in Inactive state) ◇ If you did activate something - run local Apex tests again (you won’t see damage earlier…)
- 58. #tahoedreamin Trailhead ◇ Deployment tools: https://trailhead.salesforce.com/modules/alm_deployment/units/alm_tools ◇ Efficient Deployments: https://trailhead.salesforce.com/modules/alm_deployment/units/alm_migrate_testing ◇ Plan Your Deployment: https://trailhead.salesforce.com/modules/alm_deployment/units/alm_deploy ◇ Application Lifecycle Management Basics: https://trailhead.salesforce.com/modules/alm_deployment/ units/alm_intro ◇ Learn More About Sandboxes: https://trailhead.salesforce.com/modules/alm_deployment/units/ alm_sandbox
- 59. #tahoedreamin Resources ● Process Limits: https://help.salesforce.com/articleView?id=process_limits.htm&type=5 ● Order of Execution: https://developer.salesforce.com/docs/atlas.en- us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm ● Deploying Flows https://help.salesforce.com/articleView?id=process_changesets_packaging.htm& type=5
- 60. #tahoedreamin Thanks! Q&A - Any questions? Connect with us: ◇ @meighanSF | meighanrockssf@gmail.com ◇ @stangomat | daniel.stange@die-interaktiven.de ◇ Slides at
Editor's Notes
- Guide towards the topic. Inquire, who works within a guided process Ask for bad expience etc.
- Hands up who knows this. And hands up who pushed something like that to prod It’s not about fingerpointing - we all did (and do) that in emergencies or when in hurry. But we have to do better and clean up as soon as possible
- What do we mean by enterprise patterns? It basically describes a process that reduces random or unpredictable results and therefore reduces risk for the org’s health and data integrity. Enterprise patterns basically means: Establish a workflow, make steps compliant and follow best practice in terms of quality, engineering and security standards. Then adhere to it and track that you’re following this process. Take the standards that you expect from enterprise grade software development and use them in your declarative customizations
- The most important pattern is establishing a routine for handling changes. This starts with the way you collect change requests: Let users give you some explanation - commonly refered to as a “user story” (As <role> I need <feature> so that <task/problem to solve>. The more crucial part we want to stress here is the way HOW you do changes. While Salesforce gives you the ability to change almost everything straight in production, this doesn’t mean you should work that way. If you look a little closer, Salesforce even warns you to make any changes directly in production. You might have heard this already, but a core principle to reduce or avoid an unpredictable state of your org and logic, and therefore a number one advice if you decided to treat declarative changes in the same way you treat enterprise software development: Don’t develop in your production org (except reports, dashboards and list views), don’t have even have more than a few people with the permission to bring in changes. Establish a role for this job, take care to select experienced people for this role and make sure they understand that they are the keepers of your org.
- It’s not about being perfect right from the beginning. If you didn’t document right from the beginning, you will have a hard time to “fretro-document” everything. Yet it is overly important that you keep your knowledge about the org somewhere accessible. Have you ever “inherited” an org? <Ask the audience> Did you find at least some documentation? In an ideal world, you will create an index of all object and all logic, that explains - most importabnt - the ideas and rationale - THE WHY - behind customizations. The world is not ideal - we know that. Make a humble start: Try to write down - at least for your new customization - why you did it and what you did. Whenever you touch something, make it a habit to write this kind of documentation for something that’s already there. You will see that very soon, a nice compendium to refer to will be around.
- Its important to know that everything is in a good shape before you start. There, run all local Apex Unit Tests before you start developing. Choose running local tests so that everything that run everything that i’s what creates your test coverage. No use running all unit tests because these include managed package tests - you can’t resolve errors and salesforce doesnt count them into your test coverage. If tests fail - keep a log. It’s not good and you should seek to resolve test failures. But a lok will help you and your team to identify the person / team to fix the issue. Expect these failures to happen upon your deployment too.
- Its important to know that everything is in a good shape before you start. There, run all local Apex Unit Tests before you start developing. Choose running local tests so that everything that run everything that i’s what creates your test coverage. No use running all unit tests because these include managed package tests - you can’t resolve errors and salesforce doesnt count them into your test coverage. If tests fail - keep a log. It’s not good and you should seek to resolve test failures. But a lok will help you and your team to identify the person / team to fix the issue. Expect these failures to happen upon your deployment too.
- Not so fast. T
- It’s time to complete your documentation. Does your solution match the requirements? Does is satisfy acceptance criteria?
- Does the logic work as described? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Does the logic work as described? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Does the logic work as described? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Deployment
- Deployment
- Deployment
- Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
- Relevant Salesforce Help / Documentation