All You Need to Know About Salesforce Development Best Practices in One Post

A quick guide to everything you need to know about Salesforce development best practices, which are emerging in light of Salesforce DX and other changes.

2017 was a year of change for Salesforce developers and admins. For years, we focused on what you can do with the platform. Now that the platform has achieved maturity, more attention shifted to the process that you use for Salesforce development.

A lot of this is because of the announcement of Salesforce DX. DX is a whole new developer experience, which is meant to change the way teams do Salesforce development. While this is exciting, there can be a lot of confusion – especially for IT leaders and team leads. There are new questions: Should I implement DX? Continuous Integration? Source control? What does it all mean? What is the best practice for setting up sandboxes? What is worth investing in and what is just hype?

You have a lot on your plate. You can’t attend every Dreamforce session or read every think piece on changes in Salesforce. What trends do you need to be aware of? And which can you ignore? Can someone just give me a TL;DR?

This post is intended as a simple guide to all of the recent changes in Salesforce development best practices. It covers the key terms and concepts that are emerging as Salesforce best practices. The document also provides links for further reading on each topic and presents them in an order in which each topic/concept builds upon the next.

What is Salesforce DX?

You’ve probably heard about Salesforce DX at Dreamforce or from your program architect or Salesforce account manager. It’s a good place to start because it represents the strategic vision for how Salesforce expects development to be done going forward.

In one sentence, Salesforce DX is a new methodology for doing Salesforce development.

Salesforce DX is not a product, but rather a general philosophy and a series of tooling changes that will roll out over several years. It includes a new command line interface, a new sandbox format (called scratch orgs), and some new marketing around best practices with source control. Salesforce DX affects both admins and developers.

The primary thing you need to know about Salesforce DX is that it’s not something you can buy but rather a philosophy and set of tools to adopt. You can build DX into your development pipeline or use hosted solutions for Salesforce DX like Blue Canvas. To prepare yourself to learn more about DX check out this further reading.

Further Reading:

Salesforce DX Product Page

A Developer’s First Impressions on Salesforce DX

The Future of Salesforce DX with Wade Wegner

What is Source Driven Development?

A big part of the Salesforce DX philosophy is the concept of “source driven development.” Salesforce is now encouraging (and ultimately will require if you want to use DX tooling) teams to implement source control (aka version control). Neither Salesforce nor DX are providing source control solutions. Instead, they encourage the use of best practices like using Git for source control with Salesforce.

Git – the leading tool for source control across the software industry – is an open source tool that can be used on hosted solutions like GitHub, Bitbucket and GitLab or Salesforce specific source control tools.

Source control is valuable because it provides audit trails, the ability to rollback and improves collaboration among your employees. With source control, you can avoid costly mistakes such as when one developer completely deletes the work of another.

If there is one change you can make as an IT leader to improve your Salesforce release management and development process, it would be implementing source control.

Further reading:

Atlassian Tutorial on Git and Source Control Generally

Atlassian’s Approach for Salesforce Development

Is Continuous Integration Worth the Investment?

Continuous Integration (CI) is a huge topic for teams across the industry. Maybe your development team has asked you about it or maybe you are leading the charge. CI is the concept of continuously merging code from developer branches into the master branch. It replaces the paradigm in which code is tested slowly over the course of weeks before being merged in. There are key advantages to doing this, notably that it reduces bugs and makes it faster to deploy code.

Continuous Delivery (CD) takes this idea to the next level by having you actually deliver new features to users as soon as they are tested and developed. (CI and CD are also known as DevOps)

Salesforce DX in part tries to help teams achieve CI and CD. There are many degrees of CI and CD. For your team, CD might mean a weekly release, for others it might mean multiple releases per day. The main thing to keep in mind is that it’s possible and worthwhile to invest in speeding up your deployment process. Moving away from default options like change sets is a great way to do that.

The primary benefit of implementing CI/CD is that you can deliver features faster. When you merge code continuously you see fewer errors and dependency issues. When they do arise, they are smaller and can be addressed before they compound. The longer you wait to release or merge code, the more changes your code base undergoes and the harder it is to ultimately release or the more likely you’ll hit a snag with new dependencies that have changed or been introduced.

Further Reading :

Tutorial for setting up open source CI for Salesforce with Jenkins and Ant

An executive’s guide to CI and DevOps

What are Best Practices Around Salesforce Sandboxes?

If you decide to invest in CI and CD you will need to rethink your sandbox strategy. How many do you need? Who should have them?

Most successful companies we talk to are finding that every developer should have their own sandbox. This is great for auditing and keeping track of work. You should also have an integration sandbox, preferably a partial or full copy sandbox that can be used to merge code into as features are developed. Many teams also elect for an optional UAT sandbox where tests are run – manual and automated.  

CRM Science’s Alex Sutherland has a classic talk on Sandbox management strategy that is well worth a watch if you’re trying to get up to speed on the basics of sandbox management. This single thirty minute video will give you all the tools you need to make wise decisions about sandboxes for Salesforce.

Further Reading:

Sandbox management for admins

Audit Trails, Rollback and SOX Compliance

Has your team ever run into an issue where a production bug in Salesforce affected your end users? Are you a newly public company and are implementing SOX compliance? Or maybe you’re a forward-thinking IT Director and just want to be on the cutting edge. In all cases, having the ability to audit changes is very important for running a secure, reliable and performant Salesforce instance. Source control provides much of what you need from an audit perspective. It also gives you the ability to rollback to previous states because you are continuously versioning your code as you go along. Want to rollback to how the application was yesterday? You can do that.

If you’re interested in SOX compliance for Salesforce, version control is a necessary step. But you’ll also need to set up proper delegation of duties so that code is reviewed and deployed by someone other than the person who developed it.

Further Reading

Creating a solid audit trail in Salesforce for SOX compliance

Stackoverflow on SOX Compliance and Salesforce

Test Automation

A key component of any CI/CD pipeline is test automation. If you have to wait for people to manually test all of your code, then you will be waiting for hours or days. If you can have automated scripts do the testing for you, you can know in minutes whether or not your code is safe for deployment. And this means you can unlock CI/CD for your team.

Test automation is definitely worth investing in and learning more about. But the writing of scripts can take a long time and require surprising amounts of expertise. To remove the tediousness of test writing and lower the technical barriers, you can use tools like Provar.

Further Reading:

Top 10 Benefits of Automated Testing.

What is Continuous Testing in Salesforce?  

What IDE Should I Use?

An IDE is an “Integrated Development Environment” and it’s the primary place your developers spend their time. A developer can spend up to 100% of their day in their IDE. This makes investing in IDEs worthwhile for developer productivity.

There are two major players for paid IDEs in the Salesforce ecosystem: The Welkin Suite and Illuminated Cloud. You can also use free and open source IDEs like Sublime, VS Code and Eclipse. The paid for players have specific Salesforce features that aren’t present on the free open source tools and that explains why so many developers want them.

Given how much time developer spend in their IDE they are generally a bargain.

Further Reading:

Comparison of the major Salesforce IDEs

That’s It

Though it can seem like a lot, these are the main topics that you need to focus on as an IT leader to ensure that your Salesforce team is following best practices and empowered to do their best work as quickly and as safely as possible. If you invest in these simple categories you can rest assured that your team will be able to deliver software faster than ever before without sacrificing quality.

Subscribe To The Monthly Newsletter

No Spam. No Rubbish. Just great content from the Salesforce Industry.

You have Successfully Subscribed!

2 thoughts on “All You Need to Know About Salesforce Development Best Practices in One Post

  1. “Salesforce DX is not a product, but rather a general philosophy and a series of tooling changes that..”, “The primary thing you need to know about Salesforce DX is that it’s not something you can buy but rather a philosophy and set of tools to adopt. ” you mean is free?

Add Comment