* Migrating Core Salesforce Skills * Updating pr comments * updat reference * Updating a skill * Migrating Datacloud skills * Migrating Industries cloud skills * Validating - skills fixing --------- Co-authored-by: Sandip Kumar Yadav <sandipkumar.yadav+sfemu@salesforce.com>
8.8 KiB
Salesforce Deployment Workflow Examples
This file contains practical examples of common Salesforce deployment scenarios using the deploying-metadata skill.
Example 1: Basic Production Deployment
User Request:
"Deploy my changes to production with full test coverage"
Skill Execution:
-
Pre-deployment checks
sf org display --target-org production sf project deploy start --dry-run --test-level RunLocalTests --target-org production --wait 30 -
Validation output
✓ Deployment validation succeeded ✓ Tests passed: 145/145 (92% coverage) ✓ Components validated: 23 -
Quick deploy (using validation ID)
sf project deploy quick --job-id 0Af5g00000XXXXX --target-org production -
Final output
## Salesforce Deployment Report ✓ Status: Succeeded ✓ Components Deployed: 23/23 ✓ Tests Passed: 145/145 (92% coverage) ✓ Duration: 8m 32s ### Deployed Components: - ApexClass: AccountController, ContactTriggerHandler, LeadProcessor - ApexTrigger: AccountTrigger, ContactTrigger - LightningComponentBundle: accountCard, contactList
Example 2: Selective Component Deployment
User Request:
"Deploy only the new Lightning Web Components to sandbox"
Skill Execution:
-
Identify LWC components
# Find all LWC components ls -R force-app/main/default/lwc/ -
Deploy specific directory
sf project deploy start \ --source-dir force-app/main/default/lwc \ --target-org dev-sandbox \ --test-level NoTestRun \ --wait 15 -
Output
✓ Deployment succeeded ✓ Components Deployed: - accountCard (LWC) - contactList (LWC) - opportunityBoard (LWC)
Example 3: Hotfix Deployment
User Request:
"I need to deploy an urgent bug fix in AccountController to production"
Skill Execution:
-
Verify the specific file
cat force-app/main/default/classes/AccountController.cls -
Run targeted tests
sf apex run test \ --tests AccountControllerTest \ --target-org production \ --wait 5 -
Deploy single class
sf project deploy start \ --source-dir force-app/main/default/classes/AccountController.cls \ --target-org production \ --test-level RunSpecifiedTests \ --tests AccountControllerTest \ --wait 10 -
Verification
sf project deploy report --job-id <job-id> --target-org production
Example 4: Manifest-Based Deployment
User Request:
"Deploy using the package.xml manifest for release v2.3"
Skill Execution:
-
Read manifest file
cat manifest/package-v2.3.xml -
Validate deployment
sf project deploy start \ --manifest manifest/package-v2.3.xml \ --target-org production \ --dry-run \ --test-level RunLocalTests \ --wait 30 -
Quick deploy
sf project deploy quick --job-id 0Af5g00000XXXXX --target-org production
Example 5: Scratch Org Development Workflow
User Request:
"Create a scratch org and deploy my feature branch"
Skill Execution:
-
Create scratch org
sf org create scratch \ --definition-file config/project-scratch-def.json \ --alias feature-branch-123 \ --duration-days 7 \ --set-default -
Push source
sf project deploy start --target-org feature-branch-123 -
Assign permission sets
sf org assign permset --name AdminPermSet --target-org feature-branch-123 -
Import test data
sf data import tree --plan data/sample-data-plan.json --target-org feature-branch-123 -
Open org
sf org open --target-org feature-branch-123
Example 6: Deployment Rollback
User Request:
"The deployment failed, I need to rollback to the previous version"
Skill Execution:
-
Retrieve current production metadata (if not backed up)
sf project retrieve start \ --manifest manifest/package-production.xml \ --target-org production -
Check out previous version from git
git checkout v2.2-stable -
Deploy previous version
sf project deploy start \ --manifest manifest/package-v2.2.xml \ --target-org production \ --test-level RunLocalTests \ --wait 30 -
Verify rollback
sf org open --target-org production
Example 7: Destructive Changes
User Request:
"Remove the deprecated CustomObject__c and old Apex classes"
Skill Execution:
-
Create destructiveChanges.xml
<?xml version="1.0" encoding="UTF-8"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members>DeprecatedClass1</members> <members>DeprecatedClass2</members> <name>ApexClass</name> </types> <types> <members>CustomObject__c</members> <name>CustomObject</name> </types> <version>66.0</version> </Package> -
Deploy with destructive changes
sf project deploy start \ --manifest manifest/package.xml \ --post-destructive-changes manifest/destructiveChanges.xml \ --target-org production \ --test-level RunLocalTests \ --wait 30Current SF CLI releases support this combined pattern correctly, including runs where the manifest deploys one set of components while a destructive changes file deletes different components in the same operation.
Example 8: Multi-Environment Deployment
User Request:
"Deploy to dev, then staging, then production after each passes validation"
Skill Execution:
-
Deploy to Dev
sf project deploy start --target-org dev --test-level NoTestRun --wait 10 -
Deploy to Staging
sf project deploy start --target-org staging --test-level RunLocalTests --wait 20 -
Validate Production
sf project deploy start --target-org production --dry-run --test-level RunLocalTests --wait 30 -
Deploy to Production (after manual approval)
sf project deploy quick --job-id <validation-job-id> --target-org production
Example 9: Code Coverage Analysis
User Request:
"Check my code coverage and identify classes that need more tests"
Skill Execution:
-
Run all tests
sf apex run test \ --test-level RunLocalTests \ --target-org dev \ --code-coverage \ --result-format human \ --wait 15 -
Analyze coverage report
Overall Code Coverage: 87% Classes with <75% coverage: - LeadProcessor: 62% - OpportunityHelper: 71% - AccountBatchProcessor: 45% Recommendations: 1. Add test methods for LeadProcessor.processLeads() 2. Test error handling in OpportunityHelper 3. Create comprehensive tests for AccountBatchProcessor
Example 10: Deployment Error Recovery
User Request:
"Deployment failed with 'INVALID_CROSS_REFERENCE_KEY' error"
Skill Execution:
-
Analyze error
Error: INVALID_CROSS_REFERENCE_KEY Component: CustomObject__c.SomeLookupField__c Message: Field references non-existent object -
Identify dependency
grep -r "ReferencedObject__c" force-app/ -
Solution provided
The error indicates that SomeLookupField__c references an object that doesn't exist in the target org. Solutions: 1. Deploy the referenced object first 2. Include both objects in the same deployment 3. Update the field to reference a different object 4. Check if the referenced object exists: sf org list metadata --metadata-type CustomObject -
Deploy with dependencies
# Include both in manifest sf project deploy start \ --manifest manifest/package-with-dependencies.xml \ --target-org production
Tips for Successful Deployments
- Always validate first - Use
--dry-runfor production - Monitor test execution - Watch for test failures early
- Check code coverage - Ensure >75% minimum
- Deploy incrementally - Smaller deployments are easier to troubleshoot
- Use version control - Tag releases for easy rollback
- Document changes - Keep deployment logs
- Test in sandbox - Never test directly in production
- Handle dependencies - Deploy referenced metadata first
These examples demonstrate common patterns. The deploying-metadata skill adapts to your specific use case and provides guided assistance.