We all fight what’s right
From our mothers telling us to clean up our rooms, to Stephen Covey’s “Sharpen the Saw*,” we all are too busy fighting fires and tending to our “regular” work. No time for housekeeping. (*habit #7 – Google it).
And nowhere is this more prevalent than the IT department where it seems there’s always a fire. But moms are always right! Picking up your clothes lets you find your toys faster. Putting your toys (/files) back in the right spot helps you find them faster next time. Your mom was the first IT manager — who knew?
For IT departments, that housekeeping can be called DevOps. It’s the intersection of software operations/procedures and development. It’s often a combination of tools and policies/procedures
Many see DevOps as a luxury, or a nice-to-have. And let’s be honest – it can be (initially) disruptive. But it’s worth exploring how accurate that luxury sentiment is.
What’s at stake
- Speed things up
- Reduce errors,
- Lastly, and as a result of the former, improve ROI
Much has been written about the benefits of DevOps – whole books in fact – so we’ll skip that. But it’s worth calling out the end-game: ROI.
ROI is a priority for any organization. Whether it’s improved productivity for the same amount of resources, or straight cost savings.
Let’s talk Salesforce – Salesforce Development and DevOps
DevOps for SFDC — is that a thing? Yes, it can be. If you put in the effort.
Salesforce doesn’t provide the necessary tools to develop at the level anywhere approaching DevOps. Typical tools are simply for org-to-org migrations and assume that the Orgs themselves are the “source of truth” for code.
Anyone who has developed on a platform or language other than SFDC knows that the Repository is the source of truth. We need to, at the very least, adopt version control with a repository and branching.
With proper tools and practices, you can save those weekends and nights when you’re in the final throes of a release and your manual systems have reached their limits.
How to get started
Start with a discussion. Then find a window of time to assess options and vendors, and then find a window to implement it. Wow, that’s a lot! Now we’re back to giving up and marching ahead with our manual mess…
Maybe, we should consider setting aside X% of time all year for DevOps, rather than trying to “squeeze it in,” or save it for when we “have time?”
ROI should always be a P1 issue, and DevOps is the path to that ROI.
So make DevOps a P1.
For more on SFDC DevOps, ping me, or comment below.