Managed Packages
You probably have already noticed the occasional qualification of ‘unmanaged’ used with packages. There are actually two types of packages: managed and unmanaged.
A managed package is designed to serve the needs of developers who are looking to sell their applications for use in other Force Platform organizations. Managed packages differ from unmanaged packages in the following ways:
Managed packages are designed to be upgradeable. Unlike an unmanaged package, which will not install if any like-named components are in the target organization, a user can install a newer version of a managed package over an older one.
Users cannot see your Apex code in a managed package, which protects your intellectual property.
Managed packages can use the Force Platform License Management technology to monitor and manage licenses.
The installing organization cannot make destructive changes to an application that is part of a managed package, although some components can be edited by subscribers.
Managed packages also have some restrictions on how they are created and deployed.
A managed package must have a namespace prefix defined. A namespace, as discussed in Chapter 12: Extended Visualforce Components and Controllers, isolates components by making their names unique when combined with a component name.
A managed package can only be developed in a Developer Edition organization, whereas all editions can create unmanaged packages.
Each Developer Edition organization can only contain one managed package, while there is no limit to the number of unmanaged packages.
Managed packages have many other characteristics and capabilities. If you are a prospective independent software vendor (ISV) who is intending to distribute Force Platform applications, you should review the online documentation on managed packages, as well as the additional information described in the Code Share project for this chapter.
How to deploy?The bottom line to this entire discussion of deployment centers on a simple question—which method should you use to deploy your applications? You should generally go with the simplest method you can use that will completely address your needs. The core of the answer to this question revolves around whether you have access to users in both the originating organization and the target organization. A Force Platform IDE deployment is quite simple, but the deployment is done by a single administrator who must have access to both the source and target organizations. With the IDE, each individual deployment is a separate process. The Force Platform Migration Tool allows you to automate this process with scripts, so you can deploy to multiple organizations without having to do each one by hand. If you have access to both sides of the deployment, and you are only deploying to a small number of targets, using the Force Platform IDE is probably the best method. If you have access to both organizations and are deploying to a larger number of servers, or if you are repeatedly deploying to a set of organizations, the Force Platform Migration Tool is probably your best choice. Packaging separates the publishing of an application from the installation of the application in another organization, so you can perform a single publishing operation and have many other organizations install the result. The most crucial difference between this one-to-many deployment method and the use of the Force Platform IDE is the publish and subscribe model, which separates the task of making an application (or a set of components) available and the task of installing them in a target organization. The packaging method is required if you do not have access to the target organization—the typical scenario for an independent software vendor (ISV) who is selling a product to a wider audience. The procedure for making a package is also built into the Force Platform Setup menu, so creating a package is a fairly easy task. Because of this, you might want to consider using packages to create one-off templates to act as a starting point for the development of other applications. Unmanaged packages cannot tolerate any component name conflicts, so distribution through unmanaged packages will work for scenarios where the package is only being installed once. Although a target organization can uninstall an existing package and install a new version, this procedure is more resource intensive on the part of the target organization, since uninstalling a package will delete the objects and their data. Typically, you will export the data, uninstall an unmanaged package, install the new unmanaged package and reload the data.. |