Salesforce: Deploy Unmanaged Package with Workbench

With unmanaged package, we can create a package and upload it, then with provided URL, install the package into target org. In this blog, we would like to share about using Workbench to retrieve and deploy the package. You can deploy between not related Org., such as from Developer Edition org. to Sandbox org.

Source Org.
1. Navigate to Setup | Create | Packages
2. Click New button and enter a Package Name
3. From Components tab, click Add to add Components to deploy
4. Repeat step 3 until all components added
5. No need to Upload the package

Salesforce do not provide function to download the package file, so we'll use Workbench to help this.

Open Workbench, from migration menu, select Retrieve
- leave Unpackaged Manifest blank
- In Package Name, enter the package name
- Tick Single Package

Click Next button to continue, then click Retrieve button.

Once done successfully, you can download the zip file.

Target Org.
Open new Workbench (for safety, you can use different browser or browse in Private mode), from migration menu, select Deploy, select the zip file from Browse button, select Rollback on Error, and Single Package. In this sample, I deploy the package to a DE org., so I can just select NoTestRun in Test Level, but for Production org. deployment, you need to select RunLocalTests, click Next button to continue.

Click Deploy button in next screen to confirm deployment. 

You will see the deployment status as below.

You also can see the deployment status from Salesforce web interface, go to Setup | Deployment Status, but the component will be not available here.

Check in the target org. if all components deployed successfully.


Reference: Using Workbench and Salesforce to Create and Download Packages

Salesforce: Deployment Test Levels

To deploy components from to Sandbox, or to Production via Change Set or other tools, Salesforce will offer option of test level to execute, even you just would like to validate the Change Set. I think most of admin will select Default when asked to select an option to Validate or Deploy, which is okay.

So, what is Default here mean?
If you deploy to production environment, all local tests are executed if your change set contains Apex classes or triggers. If your package doesn’t contain Apex components, no tests are run.
For deployment to development environments, such as sandbox, Developer Edition, or trial orgs, no tests are run by default.

What is the other options?

Run local tests
All tests in your org 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.

Run all tests
All tests in your org are run, including tests of managed packages.

Run specified tests
Only the tests that you specify are run. Choose the test classes that provide sufficient coverage for the classes and triggers being deployed. Provide the names of test classes in a comma-separated list.

Code coverage requirements differ from the default coverage requirements when using this level in production. The executed tests must cover the deployed class or trigger with a minimum of 75% code coverage. This coverage is computed for each class or trigger individually and is different from the overall coverage percentage.

Developer ideally do not have access to Production org. When deploy components with apex class or trigger, by default deployment from a sandbox to other sandbox will not execute any tests. Only when it reach deployment to Production, by default it will execute all local test and you can't skip it.

When you have major deployment, it is recommended to select test level Run local tests when you deploy within sandboxes, this will lets you catch and fix issues before the customization are rolled out to production on a targeted deployment date.

Below sample of change set deployment contains apex class and trigger, then we validate in another sandbox.

this screenshot taken when deploy to sandbox and select Default test option

this is the same change set, but with option Run local test

Reference:

• Trailhead: Change Management - Efficient Deployments
• Trailhead: ALM - Efficient Deployments
• Deploy Changes Efficiently with Quick Deployments & Test Levels (video)
• Winter ’16 Release Notes - Choose Test Options for Change Sets
• Summer ’15 Release Notes - Choose Which Tests to Run in a Deployment
• Running a Subset of Tests in a Deployment