Salesforce code deployment

Question

We are in the unique situation of managing multiple Salesforce accounts, but having very similar setups (custom objects, fields, apex code).

I'm trying to find the best way to maintain code between the Salesforce orgs in an efficient way. If we make an update to an apex class, we'd rather not have to go into each org and manually push an update. What do you guys recommend as the best approach?

Managed Package: We don't want the package to be public, and we won't be making a profit so it doesn't make sense to pay to have it on the AppExchange. Otherwise, this seems like the ideal scenario to take advantage of automatic pushing of updates.

Unmanaged Package: Seems to fit the bill, except for the workflow of updating code. Would we just have to install the updated unmanaged package onto each org (and the deployment process is smart enough to update and not replace the components?)

Force.com Migration tool: Also seems like a feasible option. Although I envision the same scenario in which pushing updates would be hard to do.

Anyone have advice for this scenario?

Answer 1

Managing a code base across multiple environments is a common problem. Salesforce does not provide much guidance aside from packages and changes sets.

The Force.com Migration Tool is a more technical approach that can be often be over looked simply because it seems complicated. Although it will take some knowledge of apache ant, you can setup a script that would backup and deploy to multiple orgs in one step and you can even automate this using Jenkins or similar tools. for example here is an ant script that retrieves metadata from a source environment and deploys to a target:

<project name="Demo"
     basedir="."
     xmlns:sf="antlib:com.salesforce">

<property file="build.properties" />
<property environment="env" />

<tstamp />
<property name="source" value="${DSTAMP} - source" />

<target name="retrieveAndDeploy">

<echo> Retriveing from Source </echo>
<mkdir dir="${source}" />
<sf:retrieve username="${sf-source.username}" 
             password="${sf-source.password}" 
             serverurl="${sf-source.serverurl}" 
             retrieveTarget="${source}" 
             unpackaged="package.xml"
             pollWaitMillis="10000"
             maxPoll="5000" />

<echo> Validating Deployment from source to target </echo>
<sf:deploy username="${sf-target.username}" 
         password="${sf-target.password}" 
         serverurl="${sf-target.serverurl}" 
         deployRoot="${source}"
         pollWaitMillis="10000"
         maxPoll="5000"
         checkOnly="true" />  

   </target>
</project>

This pulls a manifest from a package.xml file and the login credentials would be stored in a separate file (build.properties). To run this you would simply run the command ant retrieveAndDeploy . Although, this would obviously require some set up (installing ant and/or setting up a continuous integration process). This is all outline in the Force.com Migration Tool Guide .

There are some UI's that do the same thing as part of MavensMate for Sublime Text or Eclipse, but they do not over flexibility and are usually only good for one-off deployments

This is my method of choice when deploying, especially when there is active development. You can even add source control into the mix and deploy from a git repo, but that can get sticky to manage. Either way this leaves a lot of room for customizing the deployment process.

Hope this helps!

Answer 2

I would add this as a comment to Blaine's post, but I don't have enough rep, so here is your answer.

Packages are a terrible idea for this and 100% NOT what you want.

You want to use Ant (the migration tool). A normal Ant deploy has 3 parts

1. A list of components to deploy (ie "opportunityUpdates.xml").
2. A build.properties file. here is where you define the properties used in the next file. This will include properties such as Salesforce Urls, package name you are going to deply (updated every time you deploy), and passwords.
3. a build.xml file. This is where you tell and what to do. For your specific situation, your steps might be to retrieve from QA, deploy to org1, deploy to org2

Once you do the initial set up, individual deploys take less time than putting together a change set.

Answer 3

Use Eclipse IDE with Force.com plugin. Create force.com project and sync it with org with code you would like to deploy to all other orgs. After that update force.com nature for this project and deploy code via IDE to another org. This might help

Answer 4

A managed package doesn't need to be public or on the app exchange. You can set a password on it to limit the installs.

You can also expose the required methods and classes as global.

There are some big downsides to this path if you aren't going to get it security reviewed:

1. It can be difficult to remove or change certain components once they are deployed as part of a managed package.
2. You lose access to the debug logging for classes within the managed package.

If it is something you are going to be doing frequently and it needs to be repeatable then the Metadata API or the Force.com migration tool would be good options.