Deployment Tools and Processes

Deployment Tools and Processes – Salesforce Platform Developer 1 Exam Guide

Why Deployment Tools and Processes Matter

Deployment is one of the most critical phases of the Salesforce development lifecycle. Without a solid understanding of deployment tools and processes, developers risk introducing bugs, losing metadata, or breaking production environments. For the Salesforce Platform Developer 1 exam, this topic is essential because it tests your ability to move customizations and code from one Salesforce environment to another in a reliable, repeatable, and governed manner.

In real-world projects, improper deployment can lead to downtime, data loss, and failed releases. Mastering deployment ensures you can confidently promote changes through development, testing, staging, and production environments while maintaining quality and compliance.

What Are Deployment Tools and Processes?

Deployment tools and processes in Salesforce refer to the mechanisms, strategies, and best practices used to migrate metadata (Apex classes, triggers, Visualforce pages, Lightning components, custom objects, fields, workflows, etc.) between Salesforce orgs. Salesforce provides several tools for this purpose:

1. Change Sets
Change sets are a point-and-click tool native to Salesforce that allows you to send metadata from one related org to another (e.g., from a sandbox to production).

- Outbound Change Sets: Created in the source org and sent to a target org.
- Inbound Change Sets: Received in the target org and must be manually deployed.
- Change sets require a deployment connection between orgs (configured under Deployment Settings).
- Change sets do NOT support all metadata types (e.g., they cannot delete components).
- Change sets are not version-controlled and are best suited for smaller, simpler deployments.

2. Salesforce CLI (SFDX / sf CLI)
Salesforce CLI is a powerful command-line tool used in modern Salesforce development. It is the backbone of the Salesforce DX development model.

- Supports source-driven development with version control (e.g., Git).
- Enables deployment using commands like sf project deploy start (formerly sfdx force:source:deploy).
- Works with both scratch orgs and sandboxes.
- Supports manifest files (package.xml) to define what to deploy.
- Allows retrieving metadata from an org using sf project retrieve start.
- Supports validation-only deployments (check-only) and quick deploys.

3. Metadata API
The Metadata API is the underlying SOAP/REST-based API that powers most deployment tools. It allows developers to:

- Deploy and retrieve metadata in .zip file format.
- Use package.xml manifests to specify components.
- Perform file-based deployments programmatically or through tools like ANT Migration Tool or Salesforce CLI.

4. ANT Migration Tool (Deprecated but Still Referenced)
The ANT Migration Tool is a Java/ANT-based tool that uses the Metadata API. While Salesforce has deprecated it in favor of Salesforce CLI, it may still appear in exam questions.

- Uses build.xml and build.properties files along with package.xml.
- Suitable for scripted, repeatable deployments.
- Requires Java and Apache ANT to be installed.

5. Packages (Managed and Unmanaged)

- Unmanaged Packages: A collection of metadata components that can be distributed and installed in other orgs. Once installed, all components are fully editable. They are often used for one-time distribution or templates.
- Managed Packages: Used by ISVs to distribute apps on AppExchange. Components are protected by intellectual property controls and can be upgraded.

6. DevOps Center
Salesforce DevOps Center is a newer tool that provides a UI-driven experience for source-tracking, work item management, and deployments using a Git-based workflow. While relatively new, awareness of this tool is growing in the ecosystem.

How Deployment Works – The Process

Step 1: Develop in a Sandbox or Scratch Org
All development should happen in an isolated environment — never directly in production. Salesforce offers several sandbox types:
- Developer Sandbox: Metadata only, no production data.
- Developer Pro Sandbox: Metadata only, larger storage.
- Partial Copy Sandbox: Metadata + a subset of production data (using a sandbox template).
- Full Sandbox: Complete copy of production, including all data.

Step 2: Test Thoroughly
Before deploying to production, all Apex code must meet the 75% code coverage requirement (with a best practice of 80%+). Unit tests must pass successfully.

Step 3: Choose a Deployment Method
Based on complexity, team size, and requirements, choose the appropriate tool:
- Change Sets for simple, admin-friendly deployments.
- Salesforce CLI for developer-centric, CI/CD-enabled workflows.
- Metadata API / ANT for legacy scripted deployments.
- Packages for distribution to multiple orgs or AppExchange.

Step 4: Validate Before Deploying
Many tools support a validate-only (check-only) deployment. This runs all tests and verifies that the deployment would succeed without actually committing changes. This is a critical best practice.

Step 5: Deploy
Execute the deployment. For production deployments:
- All local tests or specified tests must pass.
- Overall org code coverage must remain at or above 75%.
- Deployment can be scheduled or performed during low-traffic hours.

Step 6: Quick Deploy (Optional)
If a validate-only deployment succeeds, you can use Quick Deploy to push the validated components to production without rerunning tests. Quick deploy is valid for up to 10 days after a successful validation.

Key Concepts to Know for the Exam

- package.xml: An XML manifest file that specifies which metadata components to deploy or retrieve. It lists component types and their members.
- Deployment Connections: Must be configured between orgs for change sets to work. Found under Setup > Deployment Settings.
- Test Levels for Deployment: When deploying to production, you can specify test levels:
  • NoTestRun – No tests (only for non-production orgs or metadata-only deploys in certain cases).
  • RunSpecifiedTests – Runs only the tests you specify.
  • RunLocalTests – Runs all tests in your org except those from managed packages.
  • RunAllTestsInOrg – Runs every test in the org.
- 75% Code Coverage Rule: Applies to the overall org when deploying to production. Each individual trigger must also have at least 1% coverage (best practice: cover every trigger).
- Rollback: Salesforce does NOT provide an automatic rollback for failed deployments in the traditional sense. If a deployment fails partway, the entire transaction is rolled back (all or nothing). However, once a deployment succeeds, you must manually revert changes if issues arise.
- Destructive Changes: To delete components during deployment, you use a destructiveChanges.xml file alongside your package.xml. Change sets cannot delete components.
- Scratch Orgs vs. Sandboxes: Scratch orgs are temporary, fully configurable orgs used in Salesforce DX. They are source-driven and expire (max 30 days). Sandboxes are copies of your production org used for development and testing.

Exam Tips: Answering Questions on Deployment Tools and Processes

Tip 1: Know the Limitations of Change Sets
Change sets are commonly tested. Remember that they cannot delete components, do not support all metadata types, are not version-controlled, and require deployment connections. If a question mentions deleting metadata or needing version control, change sets are NOT the answer.

Tip 2: Understand When to Use Each Tool
The exam will present scenarios and ask which tool is most appropriate. Use this quick guide:
- Simple admin deployment between connected orgs → Change Sets
- CI/CD pipeline, version control, team collaboration → Salesforce CLI + Git
- Scripted repeatable deployment (legacy) → ANT Migration Tool
- Distributing an app to multiple orgs → Unmanaged or Managed Packages
- Deleting components from target org → Metadata API with destructiveChanges.xml

Tip 3: Memorize Test Level Options
Questions often test which test level is required or available during deployment. Remember: Production deployments require tests to pass and 75% overall coverage. Know the four test run levels (NoTestRun, RunSpecifiedTests, RunLocalTests, RunAllTestsInOrg).

Tip 4: Validate-Only and Quick Deploy
If a question mentions minimizing production downtime or avoiding rerunning tests, the answer likely involves validate-only deployment followed by Quick Deploy. Remember the 10-day window.

Tip 5: Understand package.xml
You may see questions that reference package.xml structure. Know that it specifies metadata types and member names, and it is required for Metadata API-based deployments (CLI, ANT).

Tip 6: Sandboxes and Their Types
Know the four types of sandboxes and their characteristics. A common trap question involves which sandbox type includes production data (Partial Copy and Full only) versus metadata only (Developer and Developer Pro).

Tip 7: Deployment Order and Dependencies
Salesforce deploys components in a specific order. If a question mentions deployment failures due to dependencies (e.g., a field referenced by a validation rule), ensure all dependent components are included in the deployment package.

Tip 8: No Automatic Rollback Post-Success
If the exam asks about reverting a successful deployment, remember there is no built-in rollback button. You must manually redeploy the previous version or remove the changes. However, a deployment that fails during execution is fully rolled back (transactional).

Tip 9: Watch for Keywords
Exam questions often include keywords that hint at the correct answer:
- "point-and-click" or "declarative" → Change Sets
- "command line" or "source tracking" → Salesforce CLI
- "version control" or "Git" → Salesforce DX / CLI
- "delete components" → destructiveChanges.xml via Metadata API
- "distribute to multiple orgs" → Packages

Tip 10: Practice with Real Scenarios
The best preparation is hands-on experience. Create a developer sandbox, build change sets, and also use Salesforce CLI to deploy metadata. Understanding the actual workflow will make scenario-based questions much easier to answer.

Summary

Deployment tools and processes are foundational knowledge for any Salesforce developer. The exam tests your understanding of when and how to use change sets, Salesforce CLI, Metadata API, ANT Migration Tool, and packages. Focus on understanding the strengths and limitations of each tool, the testing requirements for production deployments, and best practices such as validate-only deployments and quick deploy. With solid knowledge of these concepts, you will be well-prepared to answer deployment-related questions on the Salesforce Platform Developer 1 exam.