One thing you need to understand while adopting Salesforce DevOps is that it is not a one-time process but a journey, and there is not any magic switch that you can flip to get things done. It also needs to be noted that Salesforce DevOps usage means different things for different kinds of users. The teams involved in this journey may be interested to know where they have reached and what further steps are there on their path.
SF DevOps assessment
Based on the assessment done over many DevOps teams, we recognized that the Salesforce teams fall roughly into four categories. There are different variations within each of those, but there are many commonly identifiable characteristics too. So, leveling up from one tier to higher levels need a clear understanding or implementing similar concepts in a logical sequence.
We created a DevOps assessment, which will help users to learn more about by means of labeling teams. This effort aims to help the dedicated teams understand their SF DevOps journey and what to do next.
Here are the primary evaluation categories for the teams:
- Sandbox strategy
Sandbox strategy acts as the foundation for any given SF DevOps implementation. Salesforce is primarily a development platform. The real beauty of this platform is that it offers sandbox environments that can adequately handle the repetitive aspects of software application development like authentication, security, database management, scaling, scheme migrations, code execution, cloud hosting, etc.
You may also be surprised to see the number of teams making changes in the production environment or having a single sandbox before production. Moving up the scale, you may also have teams that then use different stages like Dev, UAT, Integration, Training Staging before the changes reach the production environment. At the far end of this scale, you also have the teams with very sophisticated and complex sandbox strategies with the refresh schedules.
- Source Control
Even though there is a growing movement around Salesforce over the last half a decade, many teams do not have a proper version control system for the salesforce environment yet. Even if they do have, it is so limited as an Ant script that runs every 24 hours for metadata backup. Often, teams may have an Apex in the Git repository. Still, they don’t have any right way to help the admins perform any proper metadata configuration as Process Builders, Workflows, or any Custom Object XML in the source control.
In all sense, source control is crucial as it allows the developer to roll back any changes which end up in trouble and restore the previous state from the backup. With the recent advents in Salesforce DX, source driven approach to development has become a major topic in the dev circles.
- Salesforce dev circles
Source driven approach to development is the foundation and backbone of DevOps strategies. This is simply a natural environment for developers as to how the fish swims in water. Any SF DevOps team which works on a programming platform like .Net or Java may not envision such a development platform not featuring any source control and may even consider it as granted as it belongs to the DevOps workflow. DevOps offers many new ways to obtain the declarative metadata and Apex into the version control effectively.
From its beginning onwards, Salesforce offers many innovative ways of deploying the changes between two distinctive environments as:
– Change sets and
– Force.com migration tool or Ant scripts
Neither of these, however, are beloved widely. Salesforce answered this concern with a brand-new way of deploying it based on modern technology as Salesforce DX. This was meant to offer the Salesforce teams a unique set of tools that they can use to build personalized DevOps pipelines. It was so revitalizing for the dev teams as such tools were used mostly by greenfield projects at that time.
As these Salesforce teams started looking more like development teams overtime, more enterprise teams came on to this platform. They began experimenting with the Continuous Integration servers as Travis, Jenkins, and Bitbucket Pipelines. One significant advantage of this is that these tools are mainly customizable. You can effectively use these to trigger the pre- and post-deployment activities like kicking off Salesforce validation and running Apex unit tests before reviewing a code. The most advanced teams can also run automated functional tests along with static code analysis.
- Testing & Quality
Whether you make any quality gateway or functional tests during the Salesforce deployment pipeline, it can say a lot about the stage you are in the DevOps journey. Even though all the teams make this a part of all their releases, more and more are lately adopting such practices as technological advancements make it easier.
- Static Code Analysis
Running a static code analysis will provide you an instant health report of your completed Salesforce code. Many open-source tools like SonarApex may give you such health scores based on bugs if any, identified security vulnerabilities or any code smells. Running static code analysis could be the first step in code review, as it will give the teams something to check and discuss. This can be fully automated to eradicate the human element, which may prevent from taking adequate actions.
Static code analysis may also help to maintain and promote the quality of long-running Salesforce applications. Most of the Salesforce applications are legacy applications or will soon be legacy apps that may run for many years to come. With a prevailing market out there for Salesforce consultants and admins, the same category of developers works on a code-set for a year or may not be the same who wrote the initial set. So static code analysis will help ensure that your resources continue to grow for Salesforce implementation in the years to come.
Along with the above, automated functional testing and release management also plays a crucial role in the Salesforce development assessment to ensure agile deployment procedures. It can help to speed up the testing cycle also and reduce any chance of human-made errors.