4

I have read many blogs and documentation for this but would love to hear from someone who can share his/her own personal experience. Please condone if the questions seem naïve. I am aware of most of them but still I need an expert's opinion.

  1. After a the components are added in the package and it is uploaded as the beta package, testers can install it in their org. What if the bugs come up? Can we make changes in the package again to resolve them?

  2. After everything is ready and the package is uploaded as Managed released, how can we resolve bugs or upgrade the package later?

  3. During package creation, namespace is prefixed before the components. So does this means all the soql, sosl and reference to VF page names will fail? For example, when we reference Page.PageName in pagereference methods?

  4. Should we have two different org, one for development and another for packaging? Or some other approach?

  5. Anything to take care when multiple developers are working to develop a managed package? Any tips?

  6. Anything important that you can think of while developing a managed package?

11

After a the components are added in the package and it is uploaded as the beta package, testers can install it in their org. What if the bugs come up? Can we make changes in the package again to resolve them?

Yes, but beta packages cannot be upgraded, so the beta testers will have to uninstall and reinstall the package to get the newer version. I recommend using sandboxes with beta packages so you can simply request a new sandbox and reinstall instead of uninstalling and reinstalling (which can take quite a bit more time if there are many manual steps involved). You shouldn't generally install beta packages into production environments.

After everything is ready and the package is uploaded as Managed released, how can we resolve bugs or upgrade the package later?

Managed packages can be upgraded. Simply fix the bugs, and provide your clients with the new installer link. When they use it, if an earlier version is installed, they will be prompted to upgrade to the newer version instead of installing anew. There's no special steps you need to take to make packages work like this, as it is part of the platform. You can also set an InstallHandler hook to migrate data or configure new features that were not part of the prior package if you desire.

During package creation, namespace is prefixed before the components. So does this means all the soql, sosl and reference to VF page names will fail? For example, when we reference Page.PageName in pagereference methods?

No. Your queries and page references will operate in the scope of your namespace. This means that all SOQL/SOSL queries will attempt to use your namespace, even if there are objects, fields, classes, and so on in their package from a different namespace or that are native to the client's own organization (e.g. things they have created that do not belong to a package). You don't generally need to prefix your code with the namespace, which makes it easier to have each developer work in a separate, non-namespaced developer edition, and migrate the code to your managed package developer edition with minimal fuss.

Should we have two different org, one for development and another for packaging? Or some other approach?

This is a matter of preference, but I would generally state that each developer should work in their own isolated developer edition, and migrate changes to the managed package organization separately. This can help reduce disasters that can occur from directly operating on the primary package's code. I would also strongly recommend a Git or Subversion repository so that you can roll back undesirable changes if you need to, and prevent developers from overwriting each other's work. If you use this approach, require developers to check code into the CVS system before they can deploy the code to the packaging organization.

Anything to take care when multiple developers are working to develop a managed package? Any tips?

Use a CVS, as mentioned before, and keep each developer in their own isolated developer edition. Consider setting up a continuous integration system, like Jenkins, to migrate committed changes to the packaged organization, and I'd also recommend that developers avoid making any changes in the packaged organization directly (use the continuous integration system to deploy these changes). It's easy for multiple developers working in the same organization to overwrite each others' changes, and you want to avoid this as much as possible. Sometimes simply communicating with each other is sufficient, but a CVS makes it much less likely that you'll do permanent damage to someone else's code.

Anything important that you can think of while developing a managed package?

The most important piece of advise is this: plan your metadata carefully, especially those classes that will be "global", ahead of time. Once packaged and uploaded to a managed package, you can't generally change their data types or delete them. Global APIs become "cooked" in, so they can be deprecated, but not removed entirely. Avoid poor naming conventions and parameters in these classes, because customers can see their contents. Of course, requirements can, and do, change, so sometimes you can't avoid this, but destructive changes should be kept to a minimum.

  • @sfdcfox- Awesome explanation. I wish I could give you a thousand reputations for this. However, I do have one more query. When a Managed Released package is upgraded, that happens through a patch update right? And this patch has to be created in the same org where the Package was developed? Am I missing anything else here? – the_phantom Jun 10 '15 at 15:18
  • After the package is uploaded as Managed Released, its metadata gets locked. This doesn't mean the components will also get locked in the Packaging environment? That can still be edited right so that developers can start working for the next release? – the_phantom Jun 10 '15 at 15:21
  • @heisenberg You can get a "patch" org for minor patches, but you need to be an ISV/partner to do so. More information about that is in the ISVForce guide. The metadata becomes "locked" in the sense that you're no longer allowed to do certain things. Fields can no longer change data types, and code can't have global functions/classes removed. These limitations also in the ISVForce guide. – sfdcfox Jun 10 '15 at 17:09
6
  1. Yes you can, in a beta package you can also still remove components. Please be aware that a beta package can only be installed on a sandbox or Developer Edition

  2. You can resolve bugs just uploading a new version of your package. If you only change existing components, you can also upload a patch.

  3. No, Salesforce will take care of the prefixes

  4. Yes definitely, in fact, you want multiple Dev Orgs depending on you dev flow (one for every release, one for every developer, one for every feature, etc.)

  5. Use a code repository!

  6. Pick your Namespace wisely, it cannot be changed. Think and check twice before you add undeletable components to your package. Beware you can't upgrade an installed Managed-Beta to a Managed-Released

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.