It's time for another badge! Today's badge is the Salesforce change management badge. This is a relatively straightforward badge covering change management concepts and best practices, including sandboxes and change sets. 

If you've ever wanted to tear your hair out with change sets or deployments that never seem to go right because code coverage isn't where it should be, then this badge is for you!

KEY CONCEPTS

What does keeping your org lean and clean mean? It means making smart customizations and maintaining accurate data. Use a consistent process to build, test, and deploy in your org. This is referred to as application lifecycle management, or change management.

• Build: In the appropriate environment, define functional requirements and develop changes.
• Test: Test your changes to verify that the changes behave as you expect and don’t deliver undesired side-effects. Then make sure to do UAT. Side note: No amount of testing is going to catch everything so don’t beat yourself up if go live doesn’t go perfectly.
• Deploy: Once testing is successfully completed, make your changes available in production. Training end users is always a best practice.

WHAT'S SAFE TO CHANGE IN PRODUCTION?

Typically, customizations that don’t affect data are safe to do in a production org, like new dashboards, reports, and email templates.

WHAT HAPPENS WHEN YOU DON'T TEST?

You should always test. Seriously. It will bite you in the butt in a major way if you don't because believe me when I tell you that people, including you, dear admin, can make mistakes, and if you don't test to cover those, you

• Workflow rules or triggers can create infinite loops.
• Logic errors in validation rules prevent anyone from saving a record.
• Page layouts confuse people instead of improving the experience.
• Downstream processes break. If you integrate with a data warehouse like we do, changing the underlying table can cause the table to be re-indexed, slowing the flow of data and making other stakeholders really mad at you. Speaking from experience here. J

Use Sandboxes and Change Sets for Safe Development

• A sandbox is a copy of your production org and contains the same metadata as production.
• As it’s isolated, you can refresh data without worry.
• Change sets send customizations from one org to another and can only contain changes you can make via the setup menu.
• Change sets can validate change sets before you send to the target org.

DEVELOP AND TEST IN SANDBOXES KEY CONCEPTS

• Developer sandboxes are meant for development and testing in an isolated environment. Includes a copy of your production org’s metadata.
• Developer Pro sandboxes are intended for development and testing in an isolated environment and can host larger data sets than a developer sandbox. These are best for QA and integration testing or user training.
• Partial copy sandboxes are intended for QA, UAT, integration testing, and training.
• Full copy sandboxes copy both metadata and all data. Only full copy sandboxes support performance testing, load testing, and staging.
• Sandbox templates allow you to pick specific objects and data to copy to your full or partial copy sandbox to control the size and content of each sandbox.

DEPLOY FROM SANDBOX WITH CHANGE SETS KEY CONCEPTS

Change sets make deploying easier!

• Change sets represent sets of customizations made to metadata that you can deploy to a connected org.
• There’s no need to download any files.
• The change set tool helps you discover which components to include.
• Reuse the set of components for another deployment by cloning the change set.
• Deploying change sets involves the following steps:

1. Authorize deployment connections.
2. Create outbound change set in sandbox.
3. Upload from sandbox to production.
4. Review inbound change and deploy!

• Side note: when adding new fields or other profile-dependent changes, you have to upload the affected profile(s) in the change set. Profiles are one of the things admins typically change in production without regard to testing first, so be careful if you’re bringing over a profile that is actually out of date, especially if it’s being used by an integration user. If you don’t include profiles in the change set, no profile (including yours) will have access to the field, which could really confuse you if you forget to update the production profiles.

EFFICIENT DEPLOYMENTS KEY CONCEPTS

When you deploy customizations with Apex, local Apex tests are run as part of the deployment. Local tests consist of all tests in the target org that don’t originate from managed packages.

• If you have many custom apps and your org contains thousands of Apex tests, testing can slow down a deployment.
• Testing constitutes the largest part of total deployment time.
• Long testing could occasionally be interrupted by Salesforce service updates.
• Quick deployments cut down on deployment time by running tests as part of validations.
• Quick deployments enable you to schedule deployments to production with more confidence because you know the deployment will succeed and requires a shorter window of time.
• Run a quick deployment when the following requirements are met:

1. The components have been validates successfully for the target environment within the last ten days.
2. As part of the validation, Apex tests in the target org have passed.
3. Code coverage requirements are met.

• To perform a quick deployment, first run a validation with Apex test execution on the set of components to deploy.

Test levels enable you to choose which tests are run in a validation or deployment. The following test levels are available:

• RunSpecifiedTests: Only the tests that you specify are run. Choose the test classes that provide sufficient coverage for the classes and triggers being deployed.
• RunLocalTests: All tests in your org are run, except the ones that originate from installed managed packages.
• RunAllTestsInOrg: All tests in your org are run, including tests of managed packages.
• Default (no test level set): In prod, all local tests are executed if your change set contains Apex classes or triggers. If your package doesn’t contain Apex, no tests are run.