How to Create a Package Version

Updated 1 month ago by Copado Solutions

Once you have created or imported a package, the first step of your journey is done. Next, you need to create versions of the package, which you can later install on your environments. 

The package contains descriptive information, such as your package name (Copado DX Extension) or namespace (cmcSf); and your package versions contain the metadata, details about package dependencies, version number, among others.

If you want to create a package version in Copado, follow these steps:

Required Permissions:

  • Package Object and Field access, e.g., assign Copado User permission set).
  • Copado Job Engine & Functions, e.g., assign the Copado Functions and Copado Job Engine permission sets. 
  • Enable Package Creation custom permission, e.g., assign the CMC SFDX Admin permission set. 
  1. In the AppLauncher, navigate to the Package tab and select the package in which you want to create the new version. 
  2. In the upper-right corner of the page, click on the Create Package Version button. 
  3. Fill in the following fields:
    1. Required fields:
      1. Package Version Name: Give a name to your package version.
      2. Version Number: This is the version number, e.g. 10.0.1.3.
      3. Path: This is the path to your metadata source. E.g. force-app .
      4. Branch Name: Type in the branch name that has the package source code that you would like to include. This branch should already exist in your Git repository. 
    2. Other important fields:
      1. Code Coverage: Check this checkbox if you want this package to be released to a production environment, as code validation is required even if it does not have any apex included in the package. 
      2. Skip Validation: Check this checkbox if you want to create a package version without metadata validation. This will reduce the time to create a package version, and the transaction does not count against daily version creation salesforce limits. However, your package might not be installable and you cannot release it. So this checkbox should be reserved for POC scenarios mainly.
      3. Installation Key Bypass: Check this checkbox if you don’t want to provide an installation key as part of the version creation. If you want an installation key, don’t check this checkbox.
    3. Other fields:
      1. Tag: This will check a branch at a specific tag location.
      2. Definition File: The path to your project definition file.
      3. Installation Key: The password/key which will be required during installation. Please note that you can provide/update a key in Copado after the Version creation.
      4. Version Description: Provide a description of what this package version contains. 
      5. Release Notes URL: Insert the link of the Release Notes of this package version. 
      6. Post-Install URL:  Insert the link to which users are redirected after the package version installation.
      7. Post-Install Script: Specify an apex script file name in your repo/branch to run after the package version is installed.
      8. Uninstall Script: Specify an apex script file name in your repo/branch to run after the package version is removed from an org.
    4. When done, click on Create Version. A toast message in green color will appear indicating that the Job Started. Please refresh the page. 
  4. Refresh the page. After this, you’ll see that the Package Version Create job has finished. 
  5. To navigate to the new package version, navigate to the Related tab, and under Package Version click on the link of the package version record you just created. Here you’ll find all the information related to this record with its installation URLs. 

Considerations:

  • Before you can deploy the package to a prod org, you need to promote it to release. This is a security measure implemented by Salesforce to prevent untested packages from being released. In Copado you promote to release by publishing the package.
  • The prerequisite in Salesforce for a package to be available for release (or publish in Copado terms) is that validations must be run upon package version creation, as well as code coverage, even if your package does not contain any code.
  • If you plan to create a version that will be released, make sure you do NOT check the Skip Validation checkbox and DO check the Code Coverage checkbox. Check those settings before launching the version creation, especially if your package version creation takes a long time.
  • Your Dev Hub only allows a certain number of package version creations, including validations. You can run the command sfdx force:limits:api:display to see the remaining attempts. Creating a version without validation does not count against this limit; however, this may not be an option when you start your journey with packaging. Therefore, it is important to take this limit into account. 


How did we do?