Why You Should Consider Salesforce DevOps for Your Organization

Have you ever had a meal where you take that first bite and like it, but half-way through the dish you end up with a more complex and greater flavor? It's almost as if the end-result is something completely different than what you began the meal eating. Before you get too hungry, understand that this is actually a blog about how I would compare that to the experience many have with Salesforce and their journey to developmental maturity with the platform.

One of the most attractive aspects of Salesforce to many customers is their emphasis on low-code to no-code solutions that still provide access to a robustly-customizable platform that can react quickly to business changes. The platform has done an excellent job of enabling declarative development so that those who are not familiar with code are still able to customize and configure their Salesforce environment. The strong declarative platform allows companies to select from a broader skill-base than simply a traditional developer.

Many Salesforce customers think that because they can rapidly deploy with configuration that the need for programmatic development goes away. However, we have seen that large enterprise Salesforce organizations need programmatic development to meet complex business requirements like custom-branded UI, integrations with other systems, and/or building custom applications within their salesforce. As your Salesforce environment grows and requires custom development, so too must your development maturation.

Luckily, there is already wisdom to be gained from prior experience with the DevOps software development approach in other areas. If you are unfamiliar with DevOps, I suggest reading this CapTech blogpost as a good entry point.

You may be wondering if this is really as big an issue with Salesforce as it is for other platforms or areas of development. Isn't a lot of that risk already mitigated by using a platform owned and managed by someone else? Let me provide some common examples to illustrate this need.

Example: The business wants a "quick" fix resulting in a change made directly to the production environment.

Risks:

• Has the change been fully tested?
• What if it crashes your Salesforce org?
• Will your business still be able to function?
• What happens if those 'quick' changes are overwritten in the next release or don't make it back to the development pipeline?

Dev Ops Mitigation: Limitations should exist on what users can make changes to in production. Salesforce product security settings as well as some partner packages allow you to restrict those abilities. Only release managers should be making production changes.

Your organization could implement a development-to-production pipeline that would allow for proper testing and defect fixing prior to deployment. With a proper pipeline any production changes need to make their way back to development environments so that everyone works with the latest code base.

Example: Multiple feature teams are working in overlapping areas without any real cohesion or release management.

Risks:

• Is there anything to force collaboration between your teams?
• What happens when one team overrides the work of another?
• Expected features are not making it out to end-users
• Delays in deployment
• Mistrust between feature teams
• Mistrust between the business and IT groups

Dev Ops Mitigation: Using source control, automated testing, and a deployment pipeline, your development team will encounter conflicts BEFORE production and be able to resolve those before the features are deployed. Early testing will provide quality assurance that the features you expected to work do work. This automation also allows for you to scale your Salesforce operation and add more teams while still being able to manage the quality of the work.

Example: Your Salesforce group tracks changes to the metadata with spreadsheets to reference when making change-sets.

Risks:

• Who owns the Excel document?
• How do you manage the structure within Excel?
• This process is very manual and thus error-prone

Dev Ops Mitigation: DevOps enforces the use of proper version control systems such as Git. These can easily manage the metadata extracts to copy down the source and structure of your current Salesforce environment. These tools also allow for proper branching to allow teams to work at their own pace and merge with other teams' code when necessary and ready.
With proper integration, these can integrate with JIRA and other project management tools to trace the story directly to where the work is done making it easier than ever to manage your project and provide visibility to the proper audience. Associating a story or ticket ID with a piece of code breaks down the mystery black box that development can become. This will improve your work quality and reduce errors in production as it is easier for IT and Business to cooperate.

A good DevOps practice will not only solve these problems, but also improve your quality, velocity, and scalability. Having the right DevOps tools and practices will instill greater visibility and traceability into development work. You can either implement an AppExchange solution ─AutoRABIT, Gearset, and Copado being the current leaders ─ or create your own pipeline using tools such as Jenkins, GitHub, JIRA, etc. It is important to setup leading practices and habits around proper deployment and development to improve operational success. Tailoring the right DevOps solution for your Salesforce practice will only complement the customized nature of the Salesforce platform.

Trust me, those first bites of Salesforce will only get better with a proper DevOps practice!