Package Overview

Updated 3 weeks ago by Copado Solutions


A package is a logical set of metadata that represents a subset of an org.

With packages you can move to a modular approach for Salesforce development process since packages can be tested independently of other components in your org, and you are able to release them independently as well. 

The metadata components within a package can only live in one package at a time. The source for your packages is stored in a separate Git repository. Copado takes care of the handling process for you. 

You can define two types of packages:

Unlocked Packages

Unlocked packages give Salesforce customers a means to organize their metadata into a package and then deploy the metadata (via packages) to different orgs.

Unlocked packages enable a new way of working with metadata. First of all, you split or organize your metadata into logical packages (e.g. a 'Sales' package that contains sales-related components, a 'Service' package that includes case-related components, a 'Custom App' package with components from your custom app).

You can then provide your teams of developers with ownership of certain packages so that they can work on them and deploy the ones they own to production independently of other packages (e.g. deploy Account object changes by releasing a new version of the 'Sales' package).

Benefits of Unlocked Packages
  • Options for enterprise customers to organize and deploy metadata to production orgs.
  • Possibility of creating package dependencies. Please refer to the Packages Dependencies article for more information.
  • Feature branch development and testing.
  • Packages built directly from the source.
  • Ease of development and distribution of dependent packages.

For more information about unlocked packages and how to create an unlocked package, check out the article Creating an Unlocked Package.

Second-Generation Packages

Second-generation packaging (2GP) enables system integrators to create packages in a source-driven development environment. Leveraging this feature, you can develop and distribute packages to your customers.

Benefits of Second-Generation Packages
  • You can have multiple packages per namespace so that you can better organize your source and easily share Apex code. You can use public Apex classes across packages rather than global Apex classes.
  • Feature branch development and testing.
  • Packages built directly from the source.
  • Ease of development and distribution of dependent packages.

The process of creating a second-generation package is the same as that of unlocked packages, the only difference is that in the case of second-generation packages the namespace is mandatory. Please refer to the article Creating an Unlocked Package for more information about how to create a second-generation package.

First-Generation Packages

First-generation packages are created directly in a Salesforce packaging org. 

You may want to create Package records that represent managed and unmanaged packages so that you can install them in your scratch orgs and create dependencies of unlocked and second-generation packages on first-generation packages.

For more information about first-generation packages and how to create a first-generation package, check out the article Creating a First-Generation Package.

Git Packages

A Git package is a group of metadata included in a repository different from your pipeline repository. This functionality is custom built by Copado for companies wanting to group certain metadata in git while not having to deal with the Salesforce packaging process.

The benefits of Git packages are similar to those of unlocked packages. You can isolate specific metadata to develop and test an individual feature or a set of changes. 

The difference between Git packages and Salesforce packages include:

  1. Git packages do not need to be formally packaged in an installable app, but instead the Git package metadata can simply be deployed to a destination org using traditional metadata deployments. 
  2. Since Git packages are deployed with a traditional metadata deployment, they do not require refactoring of Apex code to handle dependency injection with dependent metadata not part of the Git package.

For more information about this type of packages and how you can create a Git package, check out the article Creating a Git Package.

Working with Packages

Once you have created a package, you can create a scratch org and load the metadata, making it ready for use as part of your user stories.

If a new component is created in the scratch org, and you try to commit it from a user story, Copado will prompt you to select the package where this new component should exist.

If you want to apply tags to your packages, you need to add a release to your user stories, and the release must include a version.

When the user story is promoted and then deployed, new elements are pushed to the package repository tagged with the same version as the Release record. If there is no version, the push will be done without a tag. The metadata selection will be included in the Package record. You can create a package version which will contain the latest metadata.

How did we do?