Your production org is your live Salesforce instance, and keeping it running like a champ is critical to your business and customers. How do you keep your users happy? By following common best practices for governance and application lifecycle management. We could write several Trailhead modules about those topics (and we’re working on them!). However, here in this blog post, we focus on some specific recommendations about how your choices in these areas can lead to successful deployments. Like any application, when you make changes to a production environment, you need to consider how your users will be affected.

Administering versus developing

Before we dive in, let’s clarify the difference between two types of tasks you perform in your org, which we’ll call administration and development. Administrative tasks include things like:

  • Developing email templates.
  • Creating or editing users.
  • Creating or editing permission sets and profiles.

All of these things are often done in a production org, and that’s fine. You aren’t changing or building applications when you do these things.

On the other hand, when you add a field to an object or a tab to an app or move a field around, you are changing an app (or potentially creating a new one). These are all development tasks, and that’s what we are focusing on here, whether these changes are declarative or programmatic. Best practices dictate performing development tasks outside of your production org.

Pitfalls of developing in production

What can happen if you don’t test your changes in a development environment first?

  • A workflow rule accidentally creates an infinite processing loop.
  • A change in a field’s type modifies data in ways you can’t undo.
  • A logic error in a validation rule prevents you from saving a record.
  • Page layout changes confuse people instead of improving their experience.

Sometimes a minor edit to one thing can have an unexpected cascading effect on many other things in your production org. For example, each of these tasks has a ripple effect.

  • Editing any aspect of custom objects or fields.
  • Activating critical updates.
  • Creating a new tab via the Setup UI.

Why? Because even a simple change to your data model may have far reaching consequences.
For example, let’s say you change a field’s type. This change can modify the data in ways you can’t undo, and it’ll likely cause a lot of Apex code to recompile.

The types of changes you make to develop an app could invalidate Apex bytecode, the pre-compiled, ready to execute representation of your Apex. The invalidated code needs to be recompiled. When your end users initiate an action, such as saving a record, the response from Salesforce will be delayed while the Apex code is being recompiled.

Let best practices guide you to success

You want a change management process that reinforces that development should occur outside of your production org. A change management process determines what kinds of modifications you allow on your production org, when they can occur, and who is responsible for making the changes.

As a guardian of your production org, you can follow these guidelines to avoid common pitfalls that can derail your deployment.

Change management best practices for successful deployments

We’ll say it again: When you’re developing or modifying an app, the safest place to make and test changes is in a dedicated development environment, such as a sandbox or scratch org. In fact, you must make some changes in a development environment to safeguard your production org, such as writing Apex code. Here are some suggested governance rules to encourage good development practices.

  • Minimize who can develop in production. Limit ‘customize application’ access for admins.
  • Restrict permissions to perform programmatic deployments to a small number of admins.
  • Be judicious about the changes you make via the Setup menu in production and stick to administrative tasks.

You’ll also want your change management plan to include guidelines for deployment. A general rule of thumb: avoid high impact changes during critical hours. For example, deploy when most users will be off the system. Release on a consistent schedule. Aim to release at regular intervals and on a given day of the week. For example, maybe minor releases occur at 8 PM Eastern time on the first Tuesday of every month. Try not to release near holidays or other major events.

Scheduling consistency helps with company-wide planning and sets expectations with your business users.

Good governance

Good governance practices ensure that your teams work together to support your business goals. A key element of good governance is a comprehensive release management process. If you design and document a complete release management process, everyone who works in your production org knows and understands their role in this process. A governance and change management framework directs the development process.

As your org grows, consider a development lifecycle that includes at least 3 orgs.

  • A development org. Here you create your app or apply modifications to existing apps. This is usually a sandbox or scratch org.
  • A staging org. This org is usually a sandbox where you run end-to-end tests. You might also do user acceptance testing, although often a fourth org is used for this purpose.
  • Your production org. This is where your users interact with your applications.

This multi-org approach has multiple benefits for helping to ensure a smooth deployment to production.

  • Practice the deployment to identify any issues.
  • Make sure you include everything you need in your deployment artifact. If you missed something, it will be obvious when you test it.
  • Have multiple users test out your changes (user acceptance testing).

However, before you deploy to production, you want to evaluate the impact on your user base. In general, it’s always best to avoid peak times, especially if your deployment will a cause Apex recompilation.

You can see which Apex classes will be impacted by your deployment.

  1. Before you perform your test deployment in the staging org, turn on Compile on Deploy from Apex Settings in Setup. This setting enables your staging org to mirror the behavior of your production org during deployment.
  2. Perform your deployment from development to staging.
  3. Once your deployment is complete, in your staging org, go to Apex Classes via the Setup menu. Customize the view so that you can see the Apex class name and the Is Valid column.

Any Apex class that doesn’t have the Is Valid box checked would need to be recompiled after running the same steps in production.

But there’s good news! Starting in Summer ’18, each org’s Apex code is now automatically recompiled in production when completing a metadata deploy, package install, or package upgrade. This change in behavior improves performance following metadata deploys and package updates. Previously, a deploy, install, or upgrade could leave an org with invalidated code, causing reduced performance while Apex was recompiled. This feature causes deployments to the org to invoke the Apex compiler and save the resulting bytecode as part of the deployment. A minimal increase in deployment times can occur, but Apex doesn’t need to be recompiled on first run. So the slight increase in deployment time can prevent performance issues on first run.

However, if you see a lot of classes that need to be recompiled, you definitely want to make sure that deployment happens in off-hours!

Deployment options

Customizations and feature settings, such as custom objects or account settings, Apex code, and Visualforce pages, are represented as metadata components. You have several options for moving metadata from one org to your production org.

Change sets

A change set is a release artifact that is a set of metadata changes relative to what’s in the production org. You can deploy workflows, rules, Apex classes and triggers, and other customizations from a sandbox to another sandbox, or to a production org. What gets released is only metadata that has been added or changed. You can create change sets using the Salesforce UI.

Metadata API

You can use the Metadata API to move metadata from a local file system to a Salesforce org. A popular way to deploy metadata is using the Metadata API. Similar to change sets, what gets released is only metadata that has been added or changed, and we provide some tools you can use that leverage the power of the Metadata API. The Salesforce CLI a powerful command line interface that simplifies development and build automation when working with your Salesforce org. Or if you like Java, you can use the Ant Migration Tool, a Java/Ant-based command-line utility. You can use the Ant Migration Tool to perform repetitive deployments that can be scripted and that use the same components (the same package.xml file).

Summary

By following some simple governance and change management best practices, you just saved yourself and your users a lot of headaches.

Resources

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS