While trying to figure out how to best manage my objects, using managed packages was suggested. I think this has a lot of potential, but was wondering at what point should one switch customizations over to a managed package?
For a concrete example, our main app has about ten custom objects, half a dozen related lists, over 100 custom fields on the Opportunity plus all of the supporting validation rules and workflows. Would this be a good candidate for a managed package? Why or why not?
Attribution to: Mike Chale
Possible Suggestion/Solution #1
One of the considerations for packages is if you need to preserve the data when deploying updates - if the answer is yes then you should go for managed package. With unmanaged packages, there is a potential for data loss.
Attribution to: kadmin
Possible Suggestion/Solution #2
Managed packages are really intended for distributing code outside of your own organization. A managed package includes a significant set of deployment and license management features. But, a managed package also places a number of restrictions on what can be done with the package between releases. It's not a lightweight option.
An unmanaged package might help to organize your components, but it's not a good way to distribute updates.
The more likely solution might lie in using change sets, and then cloning it for future updates, and using the change set to define your "package".
-Ted.
Attribution to: Ted Husted
Possible Suggestion/Solution #3
Managed packages are a massive hassle. Having been through dozens and dozens of implementations, and several managed package implementations, I only recommend using managed packages when you need to deploy to somewhere and guarantee the installing org will not have access to source code. This mostly applies for AppExchange apps. If you don't have this requirement, managed packages are much much much more hassle than they are worth.
The toolset for packages is really the bare minimum needed for AppExchange developers. Release packages impose very strong restrictions on future changes (e.g. can't rename or remove lots of things), but beta packages can only be installed in sandbox/test orgs, AND they require an uninstall first. This is the main reason that MP's are annoying, but there are many others: namespacing is under-implemented, code sharing between packages is annoying, salesforce imposes an odd limit of N (I think 10) namespaces being called per context, the management of package components is much more difficult than non-package, you can only create one managed package per developer org, etc. Basically not designed for the use case you mentioned and should be avoided at all costs if you don't need to hide your source code and/or install via AppExchange or TrialForce.
I manage all custom codebases by unmanaged packages with package.xml files, deployed between environments using the (Ant) Force.com Migration Tool with a set of convenience batch files for backing up, timestamping, version control, etc. It's a much easier way to go. Changesets would be a close second. I don't recommend managing deployment with Eclipse because IME it's not 100% reliable and is prone to mistakes when you have multiple people updating the source org simultaneously.
Attribution to: jkraybill
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/160