Hover for preview !

Leading Flow Engineering

"Leading Flow Engineering" explores the profound impact of integrating ancient wisdom into modern organizational settings, emphasizing personal transformation as the foundation for ethical leadership and collective flow. By cultivating insight and wisdom, individuals can develop ethical behavior and mindfulness, leading to enhanced productivity and harmony. The book provides practical strategies for fostering a culture of flow, effective communication, and continuous learning, while also addressing the challenges of knowledge work through resilience and collaboration. Managers play a crucial role in this transformation by bridging knowledge gaps and encouraging skill development, ultimately creating a compassionate and efficient work environment. Embrace this journey of transformation and discover how Buddhist principles can lead to a more balanced, ethical, and productive workplace.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

The Genesis of Salesforce DevOps

One of the earliest things that Salesforce did that set the stage for DevOps was to prevent people from changing Apex or Visualforce code directly in production (you have to change it in a sandbox and deploy it to production), and to mandate 75% minimum code coverage for Apex code. Code coverage is calculated by running all of the relevant Apex test classes (special Apex code files which function to test other Apex code) and seeing what percentage of lines of the Apex code are executed when the tests run. Code coverage does not guarantee that the tests are comprehensive. It doesn’t even guarantee that you’re actually testing anything, it just means that code runs.

These two steps forced Salesforce developers to use sandboxes, do deployment, and write unit tests, and was thus the genesis for Salesforce DevOps. Admins have reluctantly been forced to follow.

Salesforce devs are notoriously unenthusiastic about writing test code, so “test classes failing” means that they unenthusiastically wrote tests, but over time new changes have caused them to break. Devs haven’t bothered to rerun those tests and check them during development, and so the team only discovers that they’re broken when they attempt to deploy to production.

“No code coverage” means that the devs were lazy and created new Apex code but didn’t write any apex tests. That only causes problems when they attempt to deploy to production and the team discovers that there’s 0% code coverage for some classes.

‍

Original Publication Link: