Anti-patterns of DevOps practices in Salesforce Implementations
Introduction
My experience in software has always been with traditional software delivery: Programming languages, integration tools such as TIBCO and Mulesoft, then I moved to apply DevOps practices and principles in 2015.
Now that I look back, I was part of highly performant teams that practiced a lot of DevOps principles without having a clue that there was a movement calling for Developers and Operations to work together and minimize conflict of interests.
Some of the DevOps Principles (on a super super high level view) are:
- The 3 Ways
- Reliable deployments
- Infrastructure as a code
- Monitoring and analysis
- Culture of safety
- Repeatable processes
- Continuous integration
- Continuous deployment
- People processes and tools operating as a high performing organization
Recently I was given a new challenge: learn some salesforce + a managed package and implement “DevOps for Salesforce” whatever that marketing term means…
This post is about telling stories of Salesforce projects. I won't be mentioning the “DevSecOps tooling that resolves everything in salesforce”. A simple google search will bring you back some names and searching for reviews in G2 will give you more names and their reputation.
The anti-patterns presented here are an invitation to do the total opposite. It feels as when I was growing up and my grandma would tell me “Look at the life of that person and that's what you MUST NOT do”
Anti-pattern Stories
Advertising the system as perfect AKA hiding all the facts
One of the DevOps principles is transparency. If a project begins with hiding facts, minimizing the talk about system challenges and just highlighting the benefits and always mentioning a single client as a success story… be very aware.
Salesforce IS NOT traditional software. There are multiple challenges and complexities to achieving healthy DevOps practices in Salesforce Software delivery lifecycles SDLC. To shorten the term and replicate what many companies do, we will use a euphemism and call the Salesforce SDLC a “utopia”
When a client decides to go for “utopia” is extremely important to assess the challenges and limitations present in Salesforce. To name just a few: lots of manual steps, very error-prone, deployments are a pain, using the tooling brings more trouble, big technical debt, salesforce learning curve, Salesforce release cycles.
The anti-patterns presented here are an invitation to do the total opposite
Tooling that breaks and you get stuck with it
I wouldn't mention names but here is the story…
A client purchased a Salesforce implementation with 4 managed packages. Another super-advanced “DevSecOps” tool was purchased to achieve DevOps in “utopia”. After just a few months the processes were clearly defined, processes were documented, engineers and stakeholders were trained, the tooling was heavily used. less than 50 tickets were raised for the “DevSecOps” tool.
The tool was chosen because is the only tool compatible with functionalities of some Salesforce managed packages
Dealing with terrible product development and tech support
Sometimes the team becomes part of a vicious cycle:
- While (issues are encountered) {
- Something else would break and engineers would raise tickets
- the company that developed the crappy tool or “DevSecOps” tool had a very messy support process and would not get back immediately
- Case=One of the tickets was raised because the company that developed the “DevSecOps” tool had issues with their SMTP server
- The pipeline and “utopia” was halted because the “DevSecOps” tool was broken
- More issues were raised
- when the company that developed the “DevSecOps” tool fixed some initial issues, other functionality in the “DevSecOps” tool would break
- When inquiring about the new issues, the “DevSecOps” tool company would say that they are not able to replicate the issues
- After 3 weeks the “DevSecOps” tool company would get back and say that we could have a meeting at 2:00 AM our time :-|
- Since the engineers couldn't attend the “early bird” meetings, the “DevSecOps” tool company would send a message saying that the ticket was being closed
- the “DevSecOps” tool would take a month and then have a meeting with the engineering team to apologize and say that they couldn't find any issue. The ticket would then be closed
- Once the closed tickets the “DevSecOps” tool company dared to send surveys about their terrible customer service
- Repeat While()
- }
Realizing the very traditional and useless management practices
The engineering team raised multiple concerns about the “DevSecOps” tool and the answer was: “We must use it because that is what we sold and we cant repeat the same mistake that other companies did”
After some digging, it was found that the “DevSecOps” tool is super bad and is the only tool that is compatible with the deployment of certain Salesforce managed packages.
Many companies purchase the “DevSecOps” tool just to use 1 functionality compatible with their salesforce managed package.
In terms of price that is like paying about $1000 USD monthly for only 1 functionality that you could do manually with a well designed and properly governed software delivery process.
If someone complains or disagrees then management would say “I am putting you in the background so that you don't have to deal with stakeholders. Continue the great work with the tooling and your DevOp work for the sales software (yes they even mispronounce fancy marketing words and they meant DevOps for Salesforce)
Disclaimer
The 3 stories presented here could be fictional and any scenario that reminds you of your workplace and the management that you have is just a coincidence.
My imagination is a great tool to emphasize a point.
Please comment with constructive ideas and trying to spot problems in this set of stories
