As Salesforce DevOps becomes mainstream, many teams often ask themselves, “How do I overcome DevOps adoption challenges?”
According to the GitLab Survey, 2020 was a catalyst for DevOps tool adoption. The survey of 4,300 respondents from around the world also revealed that software testing and code review remained sticking points even through 2021.
Even as enterprises, big and small take strides towards implementing DevOps, there are recurring challenges that have DevOps teams thinking, “How can I resolve or mitigate those challenges?” Is there a native Salesforce DevOps solution that understands Salesforce architecture while also offering the benefits of GIT? Or works with GIT to solve those pain points” In this blog, we discuss the top Salesforce DevOps Adoption Challenges and how Flosum helps you overcome them.
DevOps is the combination of practices and tools that increases an organization’s ability to deliver applications and services at high velocity. The end goal of DevOps is to release with confidence. By automating your software development along with your IT operations, DevOps enables you to release your software quicker with higher quality. Given today’s push for digital transformation, the short development lifecycle and continuous delivery mean you’re releasing your applications faster without breaking your existing app and with higher software quality too.
If you look at DevOps generally on any other platform, it’s all managed through code. Usually, you have a source code and then you have a file (like an XML file) where you add more code and manage your DevOps. However, as we know, Salesforce DevOps is very different because in Salesforce, admins and low code developers like business consultants can build applications with low code builder tools like app builder flows, schema builder, and many more. It’s usually just drag and drop or clicks and points to build applications.
Yet another major differentiator for Salesforce is that different personas like Salesforce admins, developers business consultants, and architects work together to build a Salesforce application. At one end of the continuum, you have low code developers who are familiar with the business and know a little bit of code to use these tools and build applications while at the other end of the continuum are the pro-code developers who use Apex, Lightning web components, Heroku or APIs to build services and applications. That’s why you cannot just adopt the latest DevOps best practice or trend as it is from other software, rather you have to optimize the process so that every persona becomes a part of it.
When most customers start their DevOps journey they typically start with Salesforce Changesets. Similarly, most customers when evaluating a DevOps solution often start with the version control system and a deployment engine in hopes of achieving a higher development velocity, quality releases, and improving developer productivity.
The right tooling such as a version control or a deployment pipeline should help achieve success in Salesforce DevOps. But it’s never that simple. Most customers are unable able to achieve the objectives that they aspire to and there’s still a significant gap to bridge. Here are some of the challenges that teams face while adopting DevOps practices for the Salesforce platform.
Very few Salesforce administrators and business consultants understand Version Control Systems and GIT. Moreover, there is also a lack of understanding of Salesforce Metadata. If you’re building applications on Salesforce, at the end of the day it’s metadata; it’s an XML packet. However, since most Salesforce low code developers are not familiar with them, a lot of low code developers do not want to edit those XML packets or don’t use pro code tools for version control. There is a need to use tools that Salesforce admins can be trained in and are well within their comfort level. Providing comprehensive training on Version Control (Github) and Salesforce Metadata can be a great way to help low code developers overcome the skill gap. Salesforce developers can also use Sandbox Source tracking so developers can easily help Salesforce Admins and business consultants to version their changes.
Most customers when they initially adopt a DevOps system assume that information is going to flow smoothly, across the entire release management landscape, from the development Sandbox to all the way to production. But in reality, the smooth flow of information barely ever happens. As a result, it often forces developers to work together, resulting in wasted hours of excessive planning which only adds to resource overhead.
For instance, consider common examples that we see on a very frequent basis. Suppose, three developers are working on three completely different features and who have to later merge the changes into a GIT branch, which, let’s say is a UAT. Although they are working on completely independent features, because they are merging into the same branch, they are forced to work and collaborate. This is a common scenario and developers often waste a considerable amount of time in planning on who is going to merge the changes first. In this case, the client just wishes to deploy two of the three features and pull out one of the features. In such cases too, it can be hard to deploy features out of sequence or even pull out features at the last minute without creating a lot of work for the team.
Similarly, in other common instances such as where the feature has been merged and you want to pull out a feature, it is hard to demerge the feature from the same branch. Since Salesforce developers would always want to sync their branch with the org, it can often be a challenge as someone can always sneak into one of the sandboxes, make a change and those changes will not be reflected into the branch, thus causing the branch and org not in sync with each other.
Most of the time the deployments do not go through, not because of the DevOps challenges, but because of the problems are inherent within the code!
How many DevOps solutions today actually understand the code? And after understanding the code, take the right corrective action? Not many!
Talking to expert Salesforce developers worldwide, we often find that code issues are a cause for lower velocity and poor quality. You’d agree that within Salesforce, there are a lot of different metadata issues and dependency issues between different component types in Salesforce. Wouldn’t it be great if your DevOps system could understand your code, figure out which are the extra components in your code and automatically add/remove them, to fix metadata issues as well as API issues?
If the DevOps system can automatically read the code and fix the code based on the user’s acceptance of the issues, the productivity of the developers would be way higher. This is how Flosum automatically corrects a lot of the issues with a single click of a button.
When customers start using the DevOps system, the number of components in the system increases exponentially over time which affects efficiency. In the best-case scenario, ideally, you should have a couple of Orgs with the end objective to keep them in sync. Thus, you have a source of truth so everyone can build an application from that source of truth. But what we usually see is that when setting a DevOps system, you don’t have 5, 10, or 20 branches. Instead, you have thousands and thousands of branches over time. All of these branches have to be kept in sync with the org which leads to a lot of branch maintenance work and branch sync issues that customers find very hard to resolve.
Over a period of time, we see that DevOps increases overheads rather than increasing efficiency as well as creates a lot of complexity. Instead of democratizing application development, it creates silos where only certain people are allowed to touch certain aspects of the system otherwise the system would break. Ironically, despite the mentioned overheads, most of the critical issues are not solved elegantly such as rollbacks, code overwrites, merge conflicts. Thus, there is a need for a DevOps solution that addresses all the issues pertaining to the Salesforce ecosystem to meet developer’s productivity.
Salesforce has 450+ metadata types and settings. You can go to the metadata coverage report to learn more about them. It takes considerable experience to get familiar with it. Even a lot of pro code developers lack an understanding of metadata and its dependency and how everything ties up. So, it often happens that when you are deploying metadata from one org to another most of the failures are because the developers or administrators and low code builders have failed to understand metadata dependency.
Yet another challenge in Salesforce is that not all metadata types can be versioned as of today, although there’s a lot of work that’s happening to fix this under the hood. A great strategy to mitigate these challenges is to provide more education around Metadata API to Salesforce Admins and low code developers. Showing them what goes beyond the scenes and XML packets helps them understand the metadata and metadata dependency concepts better. Similarly, you can educate on how to tie work items to Metadata types because usually not a lot of Salesforce organizations or developers teams realize that there needs to be a history of the story solved or the components created. In addition to how metadata dependency can impact your app deployment speed, you must also understand which metadata types can be versioned vs. which are org dependent. Some examples of metadata types that cannot be versioned because they have sensitive information and you certainly don’t want to expose your secret information:
In fact, you should have documentation that lists what are the metadata types in your organization that you cannot version and which exist directly in the production org.
Oftentimes, in a team, people do not realize the importance of Salesforce Release Managers. So, developers are assigned the role of a Release Manager. As a result, this puts lots of stress on developers performing the role of release managers, because it involves constant communication with Dev Leads, Test Engineers, and Product Managers. This often proves to be counterproductive becasue developers are neither able to focus on their development job nor perform the responsibility of a release management job properly. A release manager has lots of responsibilities and therefore must have a combination of skills including knowledge of Salesforce metadata types and development lifecycle as well as leadership skills to manage the DevOps team.
A dedicated release manager is a no-brainer for large enterprise projects, as having a dedicated release manager will help build a release calendar, help manage interdependencies between teams as well as efficiently maintain a list of changes between environments. Choosing an all-in-one release management solution such as Flosum, the 100% native Salesforce solution, allows the DevOps team to seamlessly orchestrate changes across your development ecosystem, allowing you to avail all benefits that a release manager would deliver. It also allows you to manage interdependencies between teams, and maintain a list of changes between environments. Similarly, choosing a knowledgeable person with Salesforce metadata types and development lifecycle can help drive constant improvements.
DevOps isn’t about automation, just as astronomy isn’t about telescopes.” You might have all the tools, you might have CI/CD, and version control, but still, your DevOps strategy might be a failure. It is because DevOps isn’t just about technology and tools, it is also about people. The important thing to remember is that automation is simply a tool or method for achieving the goal. Breaking down silos and connecting people as a team is critical to make the most important part of DevOps. Getting Developers, Release Managers, and Testers to feel as thought they are part of one team, ensuring good communication channels, and celebrating each other’s accomplishments can encourage camaraderie, trust, and collaboration. These are the secret ingredients of high-performing teams and ultimately a successful DevOps strategy.
Governance is all about vision, strategy, and alignment. If you do not have a vision and strategy in place, there will likely be a lack of alignment as a result you will fail to define your software life cycle. Thus, you will see lots of bugs and enhancements and are just catching up every time. So, how can you mitigate this challenge? You can begin by charting your vision, strategy, and defining your software lifecycle management. Further, you should have a data strategy, and architectural management to help development teams that are working in parallel to avoid creating duplicate fields. With architectural management in place, you will have a proper architectural review board to monitor your application for any data model changes. This ensures that you are building a sound data model which is not replicative because replicative data models will end up becoming a major challenge to clean up. Equally important is to establish communication strategies for regular scrum meetings and architectural meetings.
Because of these underlying inefficient processes as well as the constraints of the tools you as Salesforce developers are using, we see that development velocity low, quality does not improve and business does not see the productivity gains that are expected out of the DevOps system. This is where Flosum with its unique architecture not only helps overcome the limitations mentioned above but also provides deeper integration with GIT.
Compared to other DevOps solutions, we at Flosum have created something that we call “Native Repository”. The native repository architecture intimately understands the Salesforce architecture as well as all the components of the Salesforce ecosystem. If you have any dependency issues or are missing any components, it automatically suggests you add certain components as part of the process. As a result, the velocity of the deployment skyrockets. We at Flosum understand Salesforce architecture, Salesforce Orgs, Development Sandboxes, Scratch Orgs, and all the settings extremely well and the native repository is built on the Salesforce platform and completely understands Salesforce. Yet another benefit of Native Repository, is that most customers today search for GIT branching strategy, and everyone has their own take on the best course of action. The underlying cause is that it puts constraints on customers and takes away the flexibility and agility that customers want, while native repository or Flosum with GIT provides that flexibility and agility without sacrificing the velocity that customers need.
Flosum is incredibly fast, powerful and robust. Even if you are starting out, you can do your deployment, start to finish in just 15 minutes. From code overwrites, taking care of dependencies, rollback, and more, you can do all that and more in minutes, not hours or days. It also supports a flexible GIT branching strategy minus the constraints you get because of the interdependency of branches within GIT.
Yet another reason why most financial organizations and major banks, as well as all Federal agencies such as Navy, Postal Service, Air Force, and others, trust Flosum is that Flosum never has access to your data. Discover why Flosum makes a great choice as your all-in-one solution for requirements management, version control, deployments and regression testing.