Managed packages are the recommended ways for ISVs on Force.com platform to distribute and sell their applications. With Managed package , there is lot more power to ISVs wherein :
a. They can shield their Intellectual property [ source code ] since managed packaged is like an installer without direct access to any metadata components of the application.
b. The Patch facility for minor upgrades is available for managed packages.
c. With LMA [ License Management Application ] , provided by salesforce , the package owner can control the trial licenses and have dashboard of which users are on which version.
d. Using TrialForce , you can also distribute your app to customers who don’t have Salesforce CRM for provisioning free trials and deploy applications from your own website.
ISV application release planning :
Releasing an application as an ISV would see the following package states as part of the release process.
a. Unmanaged : During the development stage , it is good be to be unpackaged mode so that your development have full access to the metadata components and freely make changes.
b. Managed- Beta : The package or component was created in the current Salesforce organization and is managed, but it is not released because either it has not been uploaded or it has been uploaded with Managed – Beta option selected . Used for limited availability for testing with select customers .
c. Managed – Released : The package or component was created in the current Salesforce organization and is managed. It is also uploaded with the Managed – Released option selected.
d. Patch : If you need to provide a minor upgrade to a managed package, consider creating a patch instead of a new major release. A patch enables a developer to change the functionality of existing components in a managed package, while ensuring that subscribers experience
no visible changes to the package.
e. Managed-Installed : The package or component was installed from another Salesforce organization but is managed
Continuous Integration Considerations for Managed Packages in Salesforce inline with support the entire packaging life cycle.
1. Namespace : Managed packages come with unique ID called Namespace. It is this namespace that differentiates your components from other’s components and help in the upgrade process.
So, the packaging and deployment automation should consider taking the namespaces as additional parameter .
2. Beta Packages : Before you release a managed package into production , you can create package of type – ” Managed-Beta” and make it available in a limited manner for Testing .
The CI tool should have supported for packaging and deployment of Beta packages into test organizations .
3. Post-Install / Post- Uninstall Scripts : There may a requirement to run Apex Code in post-install or post-uninstall in the subscriber’s organizations.
4. Dependent managed packages and their versions : Sometime some managed packages can depend on other managed packages , so before installing or upgrading a managed package , the dependent versions need to be fetched and updated to the latest version . Additionally ,for whatever be the reason , if a dependent package needs to be downgraded – then it has to be uninstalled first . This step is not required for upgrades.
5. Branching and Merging : The version control support to move the changes between the master and various feature branches is critical for ensuring that any patches that are applied on production are moved promptly into respective feature branches or dependent packages.
6. Apex Tests and Code Coverage : Any Apex code that is included as part of a package must have at least 75% cumulative test coverage. Each trigger must also have some test coverage.
7. Publish Extensions to Managed Package : An extension is any package, component, or set of components that adds to the functionality of a
managed package. An extension requires that the base managed package be installed in the organization.
8. Trialforce : Support for Trialforce org deployments and test execution .