Salesforce Code and Configuration Deployment

Following are a varied list of ways through which Code or Configuration could be deployed in Salesforce Server. It is assumed that deployment focus would be on Production instance, but it is true with Developer Edition and Sandbox instances as well.

Technical Prerequisites for a Salesforce Deployment

There are some tools and software that must be installed and properly configured on the Release Manager’s machine in order to enable the Deployment Process described in this guide. Some other tools are not required but we recommend using them. Here is a quick description of these tools.

Tool	Required / Optional	Purpose	Comment
Eclipse	Optional	Eclipse is a developer tool that supports several languages. The currently recommended version of Eclipse to download is Eclipse Kepler 4.3 (the “Eclipse for Java developers” version is recommended) and can be downloaded from http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/keplerr	Check latest version entry Eclipse should not be used to deploy metadata beyond development sandboxes
Force.com IDE	Required (only when using Eclipse)	The Force.com IDE is an extension of the Eclipse application that allows you to connect to your Salesforce sandbox, download meta-data, write code or perform configuration changes and then deploy them back to the sandbox environment.	Once you have eclipse on your PC, you will need to install the Force.com IDE.
Git Source Control	Required	Provides source code management (via a Git repository).
Code Merge tool (e.g. Kaleidoscope)	Required	Tool used to resolve conflicts in both code and object definition files (ANT exports XML files with the Salesforce definitions) when running a branch merge in Git	Kaleidoscope is a good example of this type of tool
Force.com Migration Toolkit	Required	The Force.com Migration Tool is a Java/Ant-based command-line utility, based on the Force.com Metadata API, for moving metadata between a local system directory and a Force.com org.  The toolkit is a key component for moving configuration from the Source Code Repository (Git) into other Saleforce.com environments (e.g. test sandbox or Production environment)	The toolkit will be installed on Release Mgr’s and developer’s PCs and on Jenkins as a plug-in, allowing Jenkins to be able to orchestrate the migration of meta-data.
Jenkins CI Server	Optional (we will use it for handling ANT Deploy)	Jenkins is an application that allows the orchestration of deployment jobs, deploying metadata from Git to targeted Saleforce.com environments using an ANT plugin and optionally running post-deployment jobs to test the new code.	Deployment jobs can be run in one of three ways:   •Manual   •Scheduled   •Triggered
Copado	Optional	AppExchange tool used to migrate object permissions (Profiles, Permission Sets) as well as other objects (translations) that are hard to deploy. It also includes a Git-based, automated Backup Utility and a built in Continuous Integration mechanism. It can also migrate users, roles, and all kinds of bulk data.	Migrating permissions by hand can make deployments extremely slow. There is no automated mechanism in Salesforce for this type of migration. That’s why we recommend Copado. It requires licensing.
Perm Comparator	Optional	Free tool that can be used to compare permissions between a sandbox and Prod, for example, in order to identify differences –i.e. missing permissions.	It can be found here: https://perm-comparator.herokuapp.com/
Selenium	Optional	Selenium is used to automate web browser testing (UI). If applied already at developer level this helps to increase code quality.

Manually

 If changes are really small and minor then it could directly be done in the Production instance.

Change Set

ANT Migration Tool

How to use "Apache Ant" a Force.com Migration Tool

Pros & Cons

Pros

• Much more flexible and that is why used in Continuous Integration (CI)
• Can be scheduled for a nightly job for auto deployment
• Has been seen as the tool of choice for deployment, thus widely accepted and regularly updated by Salesforce.com Team

Cons

• Has some learning curve due to scripting

Further Questions or concerns to ponder around.

Q. During deployment action, how can I auto backup the target components? Just like Archive option feature in force.com IDE deployment, where it archives both Source and Destination deployed components.

Force.com IDE (Eclipse)

Points to be noted before executing deployment.

1. It is a good idea to have separate Eclipse Force.com IDE Project containing the requirement related changes.
2. Make sure package.XML file contains only deployable components. Otherwise, deployer would validate for deletion of those components and not present in the package. In other words, it would assume that you are trying to delete the component but resource/code/config is missing from the zip file.

Here are the simple steps to follow:

1. Create an Eclipse force.com project that contains only the component which needs to be deployed. Also, this would make your work-package/requirement specific code segregated from other code components.
2. Project ->force.com -> Deploy to Server
3. Provide following details
1. Username
2. Password
3. Security Token
4. Environment
4. Next
5. Archive Options: Check both "Project Archive" and "Destination Archive", so that you have a backup of components for future references
6. Deployment Plan: Validate Deployment
7. Deployment Plan: Deployment Candidate: Generally, I would not delete any components and proceed with 'Add' action only.
8. Clicking Next will execute the action. Deployment Successful. If not, check the metadata as per the error message and start again.

Pros & Cons

Pros

• Visually see the components to be deployed. GUI is always better for a glance for verification
• Do not require writing scripts
• Auto Archive once archive option is selected

Cons

• Manually run the deployment compared to ANT deployment which is both manual and automated
• Can not be scheduled for Cron-Job or anything like that
• Doesn't have the level of flexibility through writing scripts

Further Questions or concerns to ponder around.

Q: When can I save my security Token, so that I do not have to enter it everytime I deploy the code in an environment?

Workbench

Preparation:

1. Create a ZIP file containing a project manifest, a file named package.xml, and a set of directories that contain the components to deploy. See Salesforce.com Metadata API Developers guide more information about working with ZIP files for deployment.
2. If you have created the project in Eclipse or MavensMate then, zip the entire content of the src folder containing package.XML file. rename the zip file as src_test_deploy_datetime.zip
3. You zip file should like following
2. test_deploy_workbench/objects/Sales__c.object (Sales__c.x_test__c)
3. test_deploy_workbench/flows/Acknowledgement_Process_v3-10.flow
4. test_deploy_workbench/package.xml
4. Make sure the package.XML file and folders contain only those components that need to be deployed.

Steps to follow:

1. Login to the environment using URL https://workbench.developerforce.com/metadataDeploy.php where the package needs to be deployed.
2. Migration -> Deploy
3. Browse the packaged zip file
4. Choose applicable options
• Rollback on Error = True
• Single Package = True
5. Next
6. There will be another confirmation/warning screen before you Deploy. Please check, if all options are set properly and there are no warning messages.
7. Click Deploy
8. Another screen will be shown with details of success or error message. Thus deployment completion.

Workbench Migration Options

Allow Missing Files

If files that are specified in package.xml are not in the .zip file, specifies whether a deployment can still succeed.

Do not set this argument for deployment to production orgs.

Auto Update Package

If a file is in the .zip file but not specified in package.xml, specifies whether the file is automatically added to the package. A retrieve() is issued with the updated package.xml that includes the .zip file.

Do not set this argument for deployment to production orgs.

Check Only  

Defaults to false. Set to true to perform a test deployment (validation) of components without saving the components in the target org. A validation enables you to verify the results of tests that would be generated in a deployment, but doesn’t commit any changes. After a validation finishes with passing tests, it might qualify for deployment without rerunning tests. See deployRecentValidation().

Ignore Warnings  

Indicates whether a warning should allow a deployment to complete successfully (true) or not (false). Defaults to false.

The DeployMessage object for a warning contains the following values:

problemType—Warning

problem—The text of the warning.

If a warning occurs and ignoreWarnings is set to true, the success field in DeployMessage is true. If ignoreWarnings is set to false, success is set to false and the warning is treated like an error.

This field is available in API version 18.0 and later. Prior to version 18.0, there was no distinction between warnings and errors. All problems were treated as errors and prevented a successful deployment.

Perform Retrieve  

Indicates whether a retrieve() call is performed immediately after the deployment (true) or not (false). Set to true in order to retrieve whatever was just deployed.

Purge On Delete  

If true, the deleted components in the destructiveChanges.xml manifest file aren't stored in the Recycle Bin. Instead, they become immediately eligible for deletion.

This field is available in API version 22.0 and later.

This option only works in Developer Edition or sandbox orgs; it doesn't work in production orgs.

Rollback On Error  

Indicates whether any failure causes a complete rollback (true) or not (false). If false, whatever actions can be performed without errors are performed, and errors are returned for the remaining actions. This parameter must be set to true if you are deploying to a production org. The default is false.

Single Package  

Indicates whether the specified .zip file points to a directory structure with a single package (true) or a set of packages (false).

Test Level 

• NoTestRun—No tests are run. This test level applies only to deployments to development environments, such as sandbox, Developer Edition, or trial organizations. This test level is the default for development environments.
• RunSpecifiedTests—Only the tests that you specify in the runTests option are run. Code coverage requirements differ from the default coverage requirements when using this test level. Each class and trigger in the deployment package must be covered by the executed tests for a minimum of 75% code coverage. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.
• RunLocalTests—All tests in your organization are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers.
• RunAllTestsInOrg—All tests are run. The tests include all tests in your organization, including tests of managed packages.

Run Tests 

A list of Apex tests to run during deployment. Specify the class name, one name per instance. The class name can also specify a namespace with a dot notation. For more information, see Running a Subset of Tests in a Deployment.

To use this option, set testLevel to RunSpecifiedTests.

References

• Workbench Technical Library https://developer.salesforce.com/page/Workbench
• Metadata API Developer Guide https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy.htm

Force.com CLI

Command-line interface to Force.com

CLI needs a deployment folder containing package.xml and directory of resources to be deployed. Run the following command to import the metadata or deploy the components.

kumamuk01@MACHINE C:\Users\kumamuk01\dev\salesforce_ant_39.0\prod\archive
> force import -directory=test_deploy_workbench -c -r -v
Not done yet: Queued  Will check again in five seconds.
Not done yet: InProgress  Will check again in five seconds.

Failures - 0

Successes - 3
Sales_Target__c.x_test__c
        status: unchanged
        id=00Nc0000001dQuCEAU
Acknowledgement_Process_v3-10
        status: changed
        id=301c0000000ESLZAA4
Imported from C:\Users\kumamuk01\dev\salesforce_ant_39.0\prod\archive\test_deploy_workbench

kumamuk01@MACHINE C:\Users\kumamuk01\dev\salesforce_ant_39.0\prod\archive

You could run varied CLI command for import. 

Here are the details of Import action which i took directly from CLI help.

> force help import
Usage: force import [deployment options]

Import metadata from a local directory

Deployment Options
  -rollbackonerror, -r    Indicates whether any failure causes a complete rollback
  -runalltests, -t        If set all Apex tests defined in the organization are run (equivalent to -l RunAllTestsInOrg)
  -checkonly, -c          Indicates whether classes and triggers are saved during deployment
  -purgeondelete, -p      If set the deleted components are not stored in recycle bin
  -allowmissingfiles, -m  Specifies whether a deploy succeeds even if files missing
  -autoupdatepackage, -u  Auto add files to the package if missing
  -test                   Run tests in class (implies -l RunSpecifiedTests)
  -testlevel, -l          Set test level (NoTestRun, RunSpecifiedTests, RunLocalTests, RunAllTestsInOrg)
  -ignorewarnings, -i     Indicates if warnings should fail deployment or not
  -directory, -d                  Path to the package.xml file to import
  -verbose, -v                    Provide detailed feedback on operation

Examples:

  force import

  force import -directory=my_metadata -c -r -v

  force import -checkonly -runalltests

References

• Force.com CLI site - https://developer.salesforce.com/tools/forcecli