The Case for DevOps as Priority 1

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.

Also posted on my profile at LinkedIN – connect with me there. 

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *