0

I am preparing myself to the developer 1 certificate and I encountered the following question:

What are two ways a developer should deploy code from a developer org to an unrelated production org?

A) Login to the production org and set the developer org as an inbound connection in the Deployment Settings

B) Save the code to a folder on the developer's computer, create an incoming Change Set in the prodcution org and upload the file directly."

C) Setup a Salesforce to Salesforce connection and deploy a Change Set

D) Package the code as an unmanaged package and install it in the production org.

E) Use an IDE to upload the new code directly into the production org using the metadata API

I know that the correct answers are D) and E). But I do not know the topic of deployment from Developer org an unrelated production org and can not find any article on it. Help me, please.

I know the right answers just because I was given them along with the question.

  • 1
    So, what's your actual question? How to do it? Documentation? Something else? – sfdcfox Aug 2 '18 at 18:22
  • @sfdcfox, I am sorry for confusion. My actual question is about documentation. – iloveseven Aug 2 '18 at 18:48
  • @iloveseven where did you saw that question, please tell? – Remario Nov 10 '18 at 15:12
3

Use change sets to send customizations from one Salesforce org to another. For example, you can create and test a new object in a sandbox org, then send it to your production org using a change set. Change sets can only contain modifications you can make through the Setup menu. For example, you can’t use a change set to upload a list of contact records. Change sets contain information about the org. They don’t contain data, such as records.

Sending a change set between two orgs requires a deployment connection. Change sets can only be sent between orgs that are affiliated with a production org. For example, a production org and a sandbox, or two sandboxes created from the same org can send or receive change sets

Because your two Org's are unrelated you cannot establish a connection between them. So you can now eliminate options A,B and C.

Option D: Unmanaged packages are typically used to distribute open-source projects or application templates to provide developers with the basic building blocks for an application. Once the components are installed from an unmanaged package, the components can be edited in the organization they are installed in. The developer who created and uploaded the unmanaged package has no control over the installed components, and can't change or upgrade them. Unmanaged packages should not be used to migrate components from a sandbox to production organization.

More about packages here

Option E: After you have created application components and tested them in your own development org, you usually want to migrate them to a different org. The second org is used for testing, staging, publication, or production use by end users.

Although each metadata component lives and runs in a particular org, the metadata files you work with in the Force.com IDE are portable from one org to another. Deploying is the process of pushing your local project files into a different Salesforce org than your project’s home org. The Force.com IDE provides the Deploy to Server wizard to guide you through the deployment process.

2

Here is a reference to justify the answer of D and E

Force.com migration tool

Force.com migration tool2

Refer this where Changesets are used:

•Straight sandbox to production migrations

•Change management without using a local file system

•Auditing previously deployed changes

•Enforcing code migration paths

•Deploying the same components to multiple orgs

Also, refer An Introduction to Force.com Metadata

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.