Salesforce Developer Deployment Artifacts

salesforce-developer-deployment

https://developer.salesforce.com/page/An_Introduction_to_Packaging - done reading
https://na1.salesforce.com/help/doc/en/salesforce_packaging_guide.pdf

How to create a package

// Salesforce - Developer - Deployment - Artifacts / Packages:

In addition to deployment tools, packages are another way to move metadata 
components from one org to another. However, packages are deployment artifacts 
and not deployment tools. The main use case of packages is for ISV developers 
to distribute apps to subscribers. But they can be used also for moving changes 
between Developer Edition orgs.

Types of artifacts:

1. Unmanaged Packages (A collection of application components that can be 
   distributed and installed in other orgs.)

   Best for:

     a. One-time setup of a development environment
     b. A starting point configuration that can be customized

   Limitations:

     a. You cant’t make further changes to packaged components using subsequent 
        packages
     b. Requires a Developer Edition org

2. Managed Packages (A collection of application components with a namespace 
   that can be distributed and installed in other orgs. Managed packages can be 
   listed on the AppExchange and are upgradeable.)

   Best for:

     a. Commercial applications
     b. Functionality you want to add in multiple, possibly non-related orgs

   Limitations:

     a. Access to code is limited or hidden
     b. Unique namespace can be bothersome or a blocker
     c. Difficult to modify or delete components
     d. Requires a Developer Edition org

Some components can only be packaged on custom objects that you write, not on 
standard objects.

A package is a bundle of components that make up an application or piece of 
functionality that you are building. Packages are typically created so that 
their components can be clustered in a container for code migration, editing in 
an IDE, or distribution to other companies in the example of AppExchange 
packages. Packages are completely private to your salesforce instance, unless 
uploaded and published to AppExchange.

Packages come in two forms: unmanaged and managed. Unmanaged packages can be 
used for a one-time distribution, like a template. These are ideal for sharing 
or migrating application templates or code samples. The installer receives an 
independent copy of the components. Managed packages provide intellectual 
property protection (the source code of many components is not available, in 
contrast to unmanaged packages), as well as a way for the package creator to 
offer upgrades to the package. Managed packages are a great way of releasing 
applications for sale, and also provide support for license enforcement 
features.

A package can range from a simple Apex class to a set of hundreds of these 
components. Each component may have dependencies, in which case the dependencies 
are automatically added. For example, if you add a Visualforce page to a 
package, and that page relies on a custom controller, then the custom controller 
will be added to the package as well, automatically. Likewise if that 
automatically added custom controller class had a dependency on another 
component, that other component will also be added, and so on.

Unmanaged packages are bundles of components that are primarily created to 
distribute components, together with their source code. For example, the package 
created in the tutorial was an unmanaged package. If you install the package, 
not only can you execute the Apex class distributed in that package, but also 
view the source code of that Apex class.

For all intents and purposes you can think of unmanaged packages as creating a 
zip and handing it off to someone—you no longer have control over an 
installation of that package. It is distribution-by-copy. If someone clicks on 
the install link and installs the package, they get their own copy and that copy 
is forever independent of the creator of the package. If the creator 
subsequently deletes or modifies the package, your version remains unaffected. 
As a consequence of this you can modify or delete your version of the installed 
package, and its components, as you see fit.

Unmanaged packages are great for template applications and free components that 
you want to distribute. After installation, everything that was installed as 
part of the package is open, just as if the package installer had created the 
components himself.

The namespace of the original publishing org is not used in an unmanaged 
package. If the publishing org has a namespace, that namespace is removed from 
all components when the unmanaged package is uploaded.

A great feature of packages (both managed and unmanaged) is that you can 
uninstall them. If you uninstall the package, all the components that were 
installed as part of the package are removed.

Managed packages add a whole range of functionality and behavior to packages, 
including:

1. A package installer (the person clicking on the installation link) will not 
   have access to the source code of many components, including Apex code, 
   installed as part of a managed package. This protects the package owner's 
   intellectual property.

2. A package installer is prevented from making a class of changes to an 
   installed application that would prevent seamless upgrades from occurring.

3. The package owner can offer upgrades to the package, and the package 
   installer can optionally upgrade to the latest version.

4. Installations can be tracked using the License Management Application, 
   allowing the package owner to determine who installed the application, who 
   upgraded the application, and so on.

Managed packages are created in much the same way as unmanaged packages, by 
navigating to Setup -> Create -> Packages. However, a namespace needs to be set 
as well.

A managed package that you produce must live alongside code that someone else 
may produce; it can, after all, be installed into anyone's organization. As a 
result, the platform demands that you create a namespace prefix. This prefix 
distinguishes your package and its contents from those of other developers. It 
is unique across all organizations, never changes, and is automatically 
prepended to all components.

For example: say you install a managed package that contains a Visualforce page 
called MyPage and a controller MyController, which has been placed in the XXX 
namespace. The Visualforce will then be available at a URL something like:
https://XXX.na6.visual.force.com/apex/MyPage
As a result the controller, an Apex class, will have the namespace prefix and 
the Visualforce page refers it as "XXX.MyController". The addition of namespace 
in all components installed with a managed packaged is handled automatically by 
the installation.

If someone installs a managed package, they don't get access to all the source 
code of that package. For example, if the package installs an Apex class, they 
will not be able to view the source code of that Apex class. Here is a list of 
factors that should be considered:

1. Apex class source code is completely hidden; unless the Apex class is a 
   global class in which case the global method signatures and variables are 
   exposed.

2. The source of Visualforce pages is not hidden. However, the source cannot be 
   edited.

3. The source of Visualforce Components is hidden.

4. Trigger source code is also hidden.

The AppExchange offers a number of features that enhance packaging even further:

1. A directory and search capability, making it easy to locate packages.

2. A ranking system, allowing installers to rate and review packages that 
   they’ve installed.

3. A test-drive feature, letting would-be installers test drive the application 
   before they install it.

4. A license management application can be installed, letting you control which 
   companies have licenses for your application, how many users within a company 
   may use it, and so on.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License