Salesforce deployment best practice?_问答_开发者

We are currently experimenting with the Salesforce platform to replace several in-house CRM tools, and have some code deployed already. As our codebase grows, we are starting to feel some of the pains that others have described when it comes to code organi开发者_StackOverflow中文版zation (no good namespacing / packaging, etc). We are Enterprise-level customers, and though our current experiment currently involves just one department, it is our hope that it will eventually grow to the entire company.

In an organization that has 3-4 completely different sales teams, each with different business processes, and thus different coding (in SF terms: record types, layouts, triggers, etc), what is a good way to manage deployment? Are 'packages' a good fit for this, or should the entire company play nice inside the same SF Org / namespace?

Generally, you are not going to enjoy the development experience because you have three teams that will each be trying to establish their systems. Each will be developing slightly differently because they will find different workarounds to the many problems that will arise.

You must find a way to namespace your triggers and classes: select a prefix for each team to separate their code.

Use fewer big classes: When programming in traditional OOP (e.g. Java) I like small meaningful classes. But in Salesforce there is a large overhead to manage a class. Plus there is just one large folder for all classes (yuck). So, I now build larger class files. In each file I include test code. I put trigger test code into a class (such as a controller) that operates on the same object.

To track changes and perform code reviews you can use this technique: Use the Force IDE combined with version control system such as CVS, SVN, Mercurial or Git.
Set your main production project to include everything (right click on the project ... Force.com ... project properties. In the preferences dialog expand Force.com and select Project Contents. Press Add/Remove and add everything). I have not deployed profile changes from the IDE back to production this way. Doing that might not be a good idea. But I do push back apex classes, triggers, and pages. The round trip on each save is slow! Now use the source control system to document changes but also compare versions.

Deployment from sandbox to production: I gave up on using the UI deployment tools. They work for simple things but I've found it can't handle a more complex change (new objects, tabs, application, triggers, classes, pages, layouts). I migrate the changes piece by piece from sandbox to production. With three teams this means you may need a central team that deploys final changes?

There are many ways to segregate your systems, including record types. These require code that either includes a hard coded SF Id or uses a string to perform a lookup. In both cases you don't want to distribute these strings or ids throughout your code. Think of the nightmare when you need to refactor. Instead, create a Globals class and put all your hard coded names and ids here. At least you can perform a more reasonable search and replace.

I love SF. Some things are very very easy to do. But some development tasks seems to take a very long time. Good luck

Generally you want to make sure everybody has their code and config running in one particular sandbox, so you can be sure that all the different parts work properly together and don't cause unwanted effects. Record types are a particularly handy mechanism as you can use them to determine which logic to run inside of triggers etc. for a particular record, combined with a good naming scheme people will know where to put code if something already exists, for example having one trigger on account before update is easier to maintain than two. Calling a trigger "Account_BeforeUpdate" will let everybody know what it is, so if they need to use one they can then put their code into the existing trigger, operating on certain record types only if need be.

One thing I always do before a deployment is to setup the production project inside of Eclipse along side the sandbox, ensuring that it has everything I need (layouts etc.). You can then use a diff tool to examine exactly what changes exist between the sandbox and production which is immensely valuable knowledge. Something to be wary of here, however, is that layouts etc. will often get updated in production after a sandbox is cut, meaning you may have to be careful with regards to deploying them.

Typically objects are the first thing I move, and because the API is non-destructive you can be sure you won't remove any vital fields from production!

Personally I'm really looking forward to some decent version control in Salesforce, you always need to be wary if you have multiple developers working in the same area, even though it attempts to protect against you overwriting others' changes it has happened to us on a few occasions. Hope some of this is of use!