Top 15 Concepts I Learned From: Mastering Salesforce DevOps By: Andrew Davis

1.      In a 2017 Stack Overflow International Developer Survey, Salesforce tied with SharePoint as the “most dreaded platform to develop on”, due to the complexity involved when it comes to deployments and configuration management. Although, CIOs and I.T. Directors recognized the centrality of Salesforce to their business. Therefore, Salesforce (the company) realized it needed an improved developer experience, which led to Salesforce DX.

2.      While most feel the traditional model of DevOps may not apply to Salesforce because it’s SaaS, meaning Salesforce manages the infrastructure, security, monitoring, database and performance, there is still the need for version control, continuous integration and delivery in order to help optimize the flow of changes to end users.

3.      DevOps is not about just “Dev” vs. “Ops” but rather ensuring that there is a strong cooperation between all teams who participate in producing a final system.

4.      The 4 major areas covered in this book include:

a.      Foundations - A review of what DevOps is and how it applies to a Salesforce org, along with the value that it can bring.

b.      Salesforce Development - How to maximize the ease of developing in Salesforce and the quality of the work that can be produced using DevOps best practices.

c.      Innovative Delivery - Covers the strategies of DX to emphasize breaking through the traditional pain of Salesforce deployments by delivering faster, cleaner, and more stable code through various environments.

d.      Salesforce Operations - Highlighting the importance of the Administrators to adopt the Salesforce DevOps best practices to help improve the overall health of the org, while reducing the tension between Developers and Admins.

5.      2 core elements of Salesforce DX:

a.      Version Control – the single source of truth using scratch orgs.

b.      Packaging – code and metadata being subdivided into both unlocked and 2nd generation managed packages of discreet functionality.

6.      The real meaning of Agile: while most company’s organize their work in Sprints and User Stories, if deployments are taking hours (or days) of prep and to deploy, along with inconsistency of codebases and the inability to quickly respond and recover when a deployment fails, the point of Agile is being missed. 

a.      The reference Agile Manifesto promotes 12 principles, 2 are of most importance:

         i.     Satisfy the customer through early and continuous delivery of valuable software

        ii.     Continuous attention to technical excellence and good design which embraces agility

7.      According to the State of DevOps Report, the 4 key metrics used as benchmarks to determine DevOps success are:

a.      Lead Time – Time to develop and time to deliver (from code committed to code deployed).

b.      Deployment Frequency – to production

c.      Change Fail Percentage – how often do deployments cause production outages or a hotfix being needed?

d.      Meantime to Restore – time it takes to bring production back to a working state by removing or correcting the bug that was identified.

8.      Salesforce makes it easy to build, which implies that it also makes it easy to build badly. Historically, there have been numerous discussions regarding the technical approach, but the strategical topic of continuous innovation to drive value to the organization is lacking.

9.      The biggest contribution to successful continuous delivery is those systems that are loosely coupled, by removing the dependencies on other teams as well as other components and metadata. Some techniques used to accomplish this are:

a.      Naming Conventions – to segment metadata

b.      Inheritance – among classes and object-oriented programming

c.      Dependency Injection – during runtime, and not compile time

d.      Event Driven, Pub/Sub – using enterprise service bus to orchestrate

e.      Enterprise Design, Separation of Concerns – Presentation, business logic, database, data access layers

10.  Dangers of developing in production (as convenient as it may be):

a.      Changes without testing can lead to data loss, operation failures and corruption.

b.      Changes are hard to track; metadata and audit trail does not have all the details needed.

c.      Untracked changes are hard to reverse with no working history.

d.      Propagation to lower tiered environments does not usually happen.

e.      Compliance with PCI, SOX, HIPAA may be in violation.

11.  The tension between freedom and control often occurs by giving the development team the freedom to make changes directly in production, until core functionality breaks, then causing additional controls to now be put in place. Therefore, the guiding principle is that you continue to find the freedom and control in your version control and CI system to determine the right balance.

12.  Just because you have a CI server set-up, it does not mean that you are practicing CI. 3 questions to challenge your CI:

a.      At least daily, does your entire team merge their work into a common trunk?

b.      Does every change to that common trunk trigger a comprehensive set of tests to run?

c.      If a build breaks, can it be repaired in less than 10 minutes?

13.  Key concept of code maintainability: reducing cognitive complexity by decreasing the number of “if” statement loops and other logic in a single block of code. Every piece of code should have one purpose along with a standard to strive to be self-documenting so newly added developers can understand the purpose just by reading it.

14.  There is no ‘right” team topology, but there are common failure modes. This includes areas such as:

a.      Not providing developers access to a Salesforce DX Hub

b.      Not running in an integrated environment

c.      Developers not having access to test in a production like environment

d.      Developers not being able to submit support tickets

e.      Infrequent and inconsistent release windows and team handoffs

f.       Parallel consulting partners competing, causing silos

15.  Lastly, the author provides a list of “shoulds” when it comes to the importance of DevOps:

a.      Spend more time with family and friends and not have to work weekends and evening for deployments and the aftermath of issues.

b.      The ability to make small improvements quickly without making other people wait.

c.      Be able to use our creativity of work instead of being stuck doing monotonous tasks.

d.      Solve problems once, in an automated way, so that we or our coworkers do not have to face them again.

Andrew’s book can be found on Amazon below or wherever technology books are sold.

https://www.amazon.com/Mastering-Salesforce-DevOps-Delivering-Innovation/dp/1484254724