10,000 Deployments, DevOps in Salesforce

Won lessons on managing technical change in the Salesforce ecosystem.

Salesforce and ISVs have been making huge strides in changing how we all promote code, create configurations, and grapple with org change. This pattern is accelerating and is trending in a great direction. We want to share the lessons, tricks, and tips on how to improve the way orgs can ship code with confidence.

• Teams of all sizes and technical accumen can benefit from a DevOps strategy. The balance comes from choosing tools and a structure that is right for the team’s skillset
• Resist at all costs the ability for code to be committed to shared branches that hasn’t been compilied in an org
• Your team is smart, but choose abstactions based off of their fitness and utility rather than their cleverness
• Plan for the ability to react to a real-time issue. When a hotfix is necessary, you need to move with swiftness and confidence
• Reproducibility of you configuration and environment matters. Without the ability to faithfully reproduce the technical landscape, bugs can and will eat your team’s time.
• Flags are great, a flag that does two things is dangerous
• The value of integrated CI/CD is inversely proportional to how long a deployment takes to run.
• Which SCM doesn’t matter, how and when you use it does
• Investing in flows and bindings to flows can leverage the expertise of your teammates
• Your project’s git history matters, its easier to roll back linear contributions
• Tagging can be a great way to organize your releases
• The soup is beautiful, only split your application development into multiple SFDX projects when you really can isolate configuration
• Integration tests are worth it, but they don’t need to gate all types of changes
• Release early and often, then ask your users how its going
• Tolerate weak or flaky tests at your own risk. It is worth it to make them, or to ask your Co-pilot to do so. Nothing is worse that a test set that has to be fiddled with in order to deploy
• Invest in the ability to seed a sandbox with representative data
• Custom Metadata, Application or Feature flags, with gradual rollouts save your support team headaches.
• Technical debt isn’t always bad, remember that business value is the reason we are here
• Create meaningful endpoint health checks for the external services that your org and users depend on
• Invest in the ability to replay your external requests for those moments where you can’t reach the services you need to reach
• Make the organization repo available to your wider technical team.
• Having a strategy about logs and log visibility can help you find issues in your environment sooner