Certified Platform App Builder App Deployment

App Deployment Detailed Explanation

App Deployment in Salesforce refers to the process of moving customizations, configurations, and metadata from one Salesforce environment to another, such as from a development environment (sandbox) to a live production environment. Salesforce provides various tools and processes to facilitate this.

Deployment Processes and Tools

1. Change Sets

What Are Change Sets?

• Change Sets are one of the primary tools used for deploying metadata in Salesforce.
• They allow you to package and migrate customizations (metadata) between Salesforce environments, such as from a sandbox to a production org.

Key Features:

• Supported Items:
  • Objects (Standard and Custom Objects).
  • Fields (Standard and Custom Fields).
  • Page Layouts.
  • Automation Logic (like Workflow Rules, Process Builder Flows).
• Environment-Specific: Change Sets only work between environments that are connected, such as a sandbox and its linked production org.

Steps for Using Change Sets:

1. Create Outbound Change Set:
   • In the source org (e.g., sandbox), select the metadata components you want to deploy.
2. Upload Change Set:
   • Send it to the target org (e.g., production).
3. Validate and Deploy:
   • In the target org, review the changes, validate them, and deploy.

Example Use Case:

• Deploy a new custom field and an updated page layout for the "Account" object from the sandbox to production.

2. Sandbox Environments

What Are Sandboxes?

• Sandboxes are separate Salesforce environments used for development, testing, and training. They ensure that changes can be made and tested without affecting the live production data.

Types of Sandboxes:

1. Developer Sandbox:

   • A lightweight sandbox for coding and testing.
   • Does not include production data (only metadata is copied).

2. Partial Copy Sandbox:

   • Includes a sample of production data, along with metadata.
   • Used for testing processes that require some real data.

3. Full Copy Sandbox:

   • A complete replica of the production environment, including all data and metadata.
   • Ideal for comprehensive testing, such as performance and regression testing.

Choosing the Right Sandbox:

• Use a Developer Sandbox for small changes or feature development.
• Use a Partial Copy Sandbox for user acceptance testing (UAT).
• Use a Full Copy Sandbox for large-scale testing before major releases.

3. Other Deployment Tools

Salesforce CLI (Command Line Interface)

• A powerful tool for developers and admins to manage metadata and automate deployments via commands.
• Features:
  • Deploy and retrieve metadata programmatically.
  • Automate repetitive tasks like creating scratch orgs or managing data.
• Example: Use sfdx force:source:deploy to deploy metadata from a local project to Salesforce.

Ant Migration Tool

• A Java-based command-line tool for retrieving and deploying metadata in bulk.
• Features:
  • Ideal for large-scale deployments.
  • Supports custom scripts for complex deployment workflows.
• Example Use Case: Deploy hundreds of custom fields and objects to a production org.

Comparing Salesforce CLI and Ant Migration Tool:

Tool	Best For	Skill Level
Salesforce CLI	Modern, agile deployments	Intermediate to Expert
Ant Migration	Large-scale legacy deployments	Intermediate to Expert

4. Application Packaging

What is Application Packaging?

• Packaging refers to bundling metadata into a "package" for deployment or distribution.

Types of Packages:

1. Unlocked Packages:

   • Used for internal modular deployments.
   • Enables version control and easy updates.
   • Example: Deploy a custom app for different departments in your organization.

2. Managed Packages:

   • Designed for distributing apps on Salesforce AppExchange.
   • Includes features like versioning, licensing, and upgrade paths.
   • Example: A third-party vendor creates a managed package for a project management tool and lists it on AppExchange for other customers to use.

Deployment Flow Example

1. Development in Sandbox:
   • A developer creates customizations (like objects and automation) in a sandbox.
2. Test in Sandbox:
   • Changes are tested in the Partial Copy or Full Copy sandbox.
3. Validate Change Set:
   • A Change Set is created and uploaded to the production org for validation.
4. Deploy to Production:
   • After successful validation, the Change Set is deployed to production.

Summary Table

Tool	Purpose	Use Case
Change Sets	Migrating metadata between environments	Deploy updated page layouts and automation from sandbox to production.
Developer Sandbox	Lightweight development and testing	Create new custom objects or fields.
Partial Copy Sandbox	Testing with a sample of production data	Test a new approval process with real sample data.
Full Copy Sandbox	Comprehensive testing with full production data	Test system performance before a major release.
Salesforce CLI	Command-line metadata management	Automate deployment for version-controlled projects.
Ant Migration Tool	Large-scale automated deployments	Deploy metadata for large enterprise projects.
Unlocked Packages	Modular internal app deployment	Version control for internal custom apps.
Managed Packages	Distribute apps via AppExchange	Publish a custom app for third-party use.

Beginner’s Practical Steps

1. Start with Change Sets:

   • Practice deploying a small update (like a new custom field) from sandbox to production.

2. Explore Sandboxes:

   • Understand the differences between Developer, Partial Copy, and Full Copy sandboxes by creating and experimenting with a sandbox.

3. Try Salesforce CLI:

   • Install the CLI and deploy a simple metadata component (like a custom object).

4. Learn Packaging Basics:

   • Create an unlocked package to group related metadata and deploy it as a single unit.

App Deployment (Additional Content)

App Deployment in Salesforce refers to the process of moving customizations, configurations, and metadata between different environments.

1. Change Sets

Change Sets are a point-and-click deployment tool used to migrate metadata between related Salesforce environments (e.g., Sandbox to Production). While easy to use, they have some limitations.

Limitations of Change Sets

1. Not all metadata components are supported:

• Cannot deploy:
  • Email Templates
  • Reports & Dashboards
  • Standard Object Permissions
• Workaround: Use Salesforce CLI or Ant Migration Tool for unsupported components.

2. Only works between related orgs:

• Change Sets cannot be used between unrelated Salesforce orgs.
• Workaround: Use Metadata API-based tools like Salesforce CLI or Unlocked Packages.

3. Manual dependency management:

• Dependencies (e.g., custom fields linked to objects) must be manually added to the Change Set.
• Workaround: Use Salesforce CLI, which detects dependencies automatically.

Best Practices

• Use Change Sets for small deployments between sandbox and production.
• For large deployments or cross-org deployments, use Salesforce CLI or Ant Migration Tool.

2. Sandbox Environments

Sandboxes are isolated Salesforce environments used for development, testing, and training without affecting production.

Sandbox Refresh

Why refresh a sandbox?

• Ensures the latest metadata and data from production are available in the sandbox.
• Helps identify issues before deploying to production.

Sandbox Refresh Cycles

Sandbox Type	Refresh Interval	Contains Production Data?
Developer Sandbox	Daily	No
Partial Copy Sandbox	Every 5 days	Yes (Subset of data)
Full Copy Sandbox	Every 29 days	Yes (All production data)

Effects of Refreshing a Sandbox

• All existing sandbox data is deleted and replaced with a fresh copy from production.
• All user emails are automatically deactivated to prevent accidental email notifications.

Sandbox Templates

• Available for Partial Copy and Full Copy Sandboxes.
• Allow admins to select specific objects and data to be copied, reducing storage usage.
• Example: Instead of copying all Case records, an admin can use a template to copy only high-priority Cases.

Best Practices

• Use Developer Sandboxes for coding and quick tests.
• Use Partial Copy Sandboxes for UAT (User Acceptance Testing).
• Use Full Copy Sandboxes for performance and regression testing before major deployments.

3. Salesforce CLI (Command Line Interface)

Salesforce CLI (sfdx) is a powerful command-line tool that enables automated deployments, source tracking, and metadata retrieval.

Common Salesforce CLI Commands

Command	Purpose
sfdx force:source:deploy -p force-app	Deploy metadata to a Salesforce org.
sfdx force:source:retrieve -m CustomObject	Retrieve metadata (e.g., custom objects) from a Salesforce org.
sfdx force:org:create -s -f config/project-scratch-def.json	Create a Scratch Org for development/testing.

Use Cases for Salesforce CLI

• Automated Deployments: Works well with CI/CD pipelines.
• DevOps Integration: Can be used with Jenkins, GitHub Actions, and Azure DevOps.
• Faster Development: Allows retrieving and deploying metadata in bulk, reducing manual effort.

Best Practices

• Use Salesforce CLI for DevOps automation.
• Use JSON configurations instead of manual deployments to improve consistency.

4. Ant Migration Tool

The Ant Migration Tool is a Java-based tool used for retrieving and deploying metadata using XML configuration files.

Ant Migration Tool vs. Salesforce CLI

Feature	Ant Migration Tool	Salesforce CLI
Deployment Method	Uses XML package.xml	Uses JSON and direct commands
Automation Support	Requires manual scripting	Supports CI/CD pipelines
Target Audience	Traditional IT administrators	Developers & DevOps teams

When to Use Ant Migration Tool

• When working in a legacy environment that relies on XML-based deployments.
• When using complex scripted deployments that have been built over time.
• When Salesforce CLI is not an option due to IT restrictions.

Best Practices

• For new projects, prefer Salesforce CLI over Ant Migration Tool.
• Use Ant Migration Tool for large, script-based legacy deployments.

5. Packaging (Application Deployment)

Salesforce offers different package types to modularize and distribute applications.

Differences Between Package Types

Package Type	Best Use Case	Modifiable After Deployment?	Version Control?
Unlocked Package	Internal modular deployments	Yes	Yes
Managed Package	AppExchange applications	No	Yes
Unmanaged Package	One-time deployments	Yes	No

When to Use Each Package Type

1. Unlocked Packages

• Best for internal modular deployments.
• Example: Deploying a Sales Cloud extension within a company.
• Benefit: Can be easily modified and versioned.

2. Managed Packages

• Best for commercial applications on AppExchange.
• Example: A third-party project management tool for Salesforce users.
• Benefit: Provides IP protection, version control, and upgrade paths.

3. Unmanaged Packages

• Best for one-time deployments where customization is needed.
• Example: Sharing a custom object template across Salesforce orgs.
• Limitation: No version control, making long-term maintenance difficult.

Best Practices

• Use Unlocked Packages for internal modular deployments.
• Use Managed Packages for AppExchange applications.
• Avoid Unmanaged Packages for large-scale deployments, as they lack upgrade capabilities.

Conclusion

The additional topics covered in this section refine our understanding of App Deployment:

1. Change Sets have limitations (dependency management, component restrictions, and org connections).
2. Sandbox Refresh ensures up-to-date environments, and Sandbox Templates optimize storage.
3. Salesforce CLI enables automated deployments and DevOps integration.
4. Ant Migration Tool is still useful in legacy setups, but Salesforce CLI is the modern standard.
5. Different package types should be used strategically:

• Unlocked Packages for internal modularization.
• Managed Packages for commercial AppExchange applications.
• Unmanaged Packages for one-time distributions.