In Salesforce, there are couple of ways to move metadata between environments. Here we are going to learn about Change Management which consists of 10% in Salesforce Advanced Adminstrator Exam. Without further ado, let's get into it!

NOTE: This post is written in April 2019 and content might be changed/updated overtime. The content is inspired by focusonforce.com.

Deployment Options

• When moving metadata between environments, there are certain possible of source and target environments:
  • Developer Edition -> Developer Edition
  • Related Sandbox -> Related Sandbox
  • Related Sandbox -> Related Production
  • Unrelated Org -> Unrelated Org

Change Sets

• Change Sets is the most common way to deploy metadata between related sandbox/production org through deployment connection.
• Steps to deploy metadata with Change Sets:
  1. Specify Allow Inbound Changes or Accept Outbound Changes in Setup Deployment Settings. (required to specify in both source and target organization)
     
  2. Navigate to Outbound Change Sets and create a new Change Set.
     
  3. Add Change Set Components to be deployed.
     
  4. Upload to desired target organization.
     
  5. After finished uploading, navigate to target organization Setup Inbound Change Sets. You can find the newly created Change Set in Change Sets Awaiting Deployment section.
  6. You can click Validate to check for validation or Deploy if you are ready to deploy.
  7. You can monitor the status of Change Set deployment at Deployment Status page. If deployment failed, you can click View Details to find out the error that causes the failure.
• NOTE: if you are uploading custom code based components such as Apex classes or Apex triggers, you will need to provide test case(s) that cover(s) at least 75% code coverage of the uploaded components.
• The available test options for Change Sets include:
  • Default - all local tests (no tests in sandbox)
  • Run Local Tests - all tests except those from installed managed packages
  • Run All Tests - all tests
  • Run Specified Tests - only specified test class name separated by comma , not break line!
• Special notes regarding to Change Set:
  • once the Change Set components are uploaded, you will not be able to modify the Change Set components anymore.
  • the whole transaction will be rolled back if deployment is failed.
  • Add Profiles can be used to include profile settings such as custom object and field permissions. (the role, permission sets and etc. can be added via Change Set components)
  • Change Set cannot be used to rename or remove components.
  • dependent components might require separate deployment (cannot deploy all at once)
  • not all metadata types are supported by Change Set (perform manually). For example, account teams, quote templates, web-to-lead, and etc.
  • Supported components in Change Set (to name a few):
    • App
    • Apex
    • Approval Process (order of active approval process is not included and custom fields on standard project in approval page fields need to be manually added to a Change Set)
    • Assignment Rule / Auto Response Rule / Matching Rule / Duplicate Rule
    • Custom Data Type / Custom Field /
    • Custom Label / Setting / Report Type / Metadata Type / Object and etc.
    • Compact Layout / Page Layout / Home Page Layout / Lightning Page
    • List View
    • Queue
    • Permission Set / Role / Sharing Criteria Rule
    • Report / Dashboard / Reporting Snapshot
    • Validation Rule
    • Visualforce Page / Component
    • Workflow Rule / Task / Field Update / Email Alert / Outbound Message
    • and etc.

Force.com IDE

• Force.com IDE is an Eclipse plugin that is mostly used by developers for local development and deployment.
• It can be used to deploy components to any org, including an unrelated org. For example, metadata components can be deployed from Developer Edition to Production org.
• Metadata components can be deleted from an org using Force.com IDE.
• Use of Deploy to Server wizard:
  
  1. Enter Destination Details
     a. Username (user must have Modify All Data permission)
     b. Password
     c. Security Token (needed if used by user)
     d. Environment (Production/Developer Edition, Sandbox, Pre-Release, Other)
     
  2. Specifying Archive Options - define project and destination archives in case something went wrong that requires a recovery later
     
  3. Deployment Plan - select list of items that needs to be deployed (add, delete, overwrite or take no action on components)
     
     • Validate Deployment is used to perform test of selected components to destination (no changes committed)
  4. Deployment Result - indicate whether the deployment is success or not.
     

Force.com Migration Tool

• Force.com Migration Tool is a Java/Ant-based CLI for moving metadata between local directory and a Salesforce org.
• Useful for:
  • lots of setup changes that takes a long time
  • script deployments to multiple environments
  • parameters to be used for repetitive deployments, making it suitable for multi-stage release processes
  • schedule batch deployments
  • move metadata between unrelated orgs (production -> production for example)
• 'build.xml' instructs ANT where and how to deploy and retrieve API calls.
• Components to be moved are described in 'package.xml' file.
• 'desctrutiveChanges.xml' is included to list metadata components when we need to delete certain metadata components in an org.
• Your credentials such as username and password are stored in 'build.properties' on local file system.
• Sample ANT commands: deployCode, deployZip, retrievePkg and etc.
• Check out link here for more information on deploying with ANT: https://focusonforce.com/configuration/deploying-with-ant/

Force.com CLI

• Force.com CLI is the command line interface for Force.com APIs.
• Metadata can be exported and imported.
• It allows deployments using scripted commands and automated tasks.
• Difference between Force.com Migration Tool and Force.com CLI is that Force.com CLI does not store username and password on local file system, user needs to login via command line.

Workbench

• Workbench is a lightweight online tool for deploying or retrieving metadata components in production/sandbox environment.
• NOTE: workbench is not an official salesforce.com product!
• URL: https://workbench.developerforce.com
  
• Things can be done in workbench:
  • View object information, metadata types and components.
  • Perform SOQL/SOSL query
  • CRUD action interface
  • Deploy and retrieve metadata components
  • Execute REST API via REST Explorer
  • Execute Apex Code
  • and etc.

Unmanaged Package

• Package is a bundle of components that make up an App or piece of functionality.
• Unmanaged Package can be used to distribute open source projects or application templates.
• NOTE: do not use unmanaged package to migrate metadata between related orgs such as between sandbox and production.
• Unmanaged package components can be edited once they are installed in an org.
• In contrary, Managed Package is protected, upgradeable and typically sold on AppExchange.

Well, that's all about it! I hope you guys enjoy reading it!

Post was published on 27 Apr 2019, last updated on 2 Jul 2019.

Like the content? Support the author by paypal.me!