![\"Illustration](\"https:\/\/texei.com\/dev\/wp-content\/uploads\/2018\/03\/1_0S2bJ1xkAooffrQ3dcEqmQ.png\")
<\/figure>\r\n\r\n\r\n\r\n<\/p>\r\n
From planning to releasing, DX is bringing you better tooling, and as deployment has always been a challenging part of Salesforce development. I was very curious and excited about the new features coming with Second-Generation Packaging<\/a>.<\/p>\r\n\r\n\r\n\r\n Until now, we\u2019ve been using ant through the Force.com Migration Tool, and from time to time Change Sets. I personally mostly never used managed or unmanaged package. The first thing to notice when looking at the new packaging options is that there are 2 package types :<\/p>\r\n\r\n\r\n\r\n Managed Packages are mostly used by ISVs, so we didn\u2019t go down that road.<\/p>\r\n\r\n\r\n\r\n Developer Controlled Packages on the other hands, seems to be the perfect fit for Enterprise Customers that want to replace their Change Set\/Ant tooling with a more robust solution. Looking deeper, DCPs comes in 2 flavors :<\/p>\r\n\r\n\r\n\r\n So what\u2019s the difference\u00a0? Once installed, a Locked DCP won\u2019t let you change the metadata, while Unlocked will just \u201cflag\u201d the metadata as being part of a Package, which content (code, fields, layouts\u2026) will remain editable.<\/p>\r\n\r\n\r\n\r\n This will be interesting when trying to sort your \u201chappy soup\u201d of metadata, as explained in Dreamforce session How Everyone Can Leverage Salesforce DX Packaging<\/a>.<\/p>\r\n\r\n\r\n\r\n We choose to use Unlocked DCP, because at the time of writing Locked DCPs are still in Pilot and can only be installed in Scratch Orgs and Sandboxes.<\/p>\r\n Moreover, having a Unlocked DCP installed means that we can still update our metadata, which seems a good backup plan in case we encounter any issue.<\/p>\r\n\r\n\r\n\r\n Our goal is to move our entire codebase to Salesforce DX. We did some extended testing of DX using Git and Scratch Orgs. And when DCPs come out we felt like this was the opportunity to move to the next level : put our work in Production using the DX development model from end to end.<\/p>\r\n\r\n\r\n\r\n We had just started to work on an internal tool for the project team, which we quickly built on the Lightning Platform. This was the perfect project because :<\/p>\r\n\r\n\r\n\r\n Now we had chosen a project, we were ready to start our journey to DX and DCPs\u00a0!<\/p>\r\n\r\n\r\n\r\n Using DX from the start was easier, as any metadata type currently supported by Salesforce DX can be in an unlocked package<\/a>.<\/p>\r\n So we didn\u2019t had to check the list of supported component types for Second-Generation Packages<\/a> (though you can have a look, DCP already includes almost everything).<\/p>\r\n\r\n\r\n\r\n After a few days of development, we had a clean repo with all the metadata ready to be packaged. And that\u2019s a big change between Change Set\/Ant and DCPs :<\/p>\r\n You don\u2019t start with an org from which you create\/retrieve your package. You create it directly from your source code in your repo !<\/p>\r\n\r\n\r\n\r\n The first thing to do is create a Package2. You\u2019ll need to have enabled your DevHub<\/a> and Second-Generation Packaging<\/a>, and logged in through the CLI<\/a>.<\/p>\r\n If you\u2019re not familiar with Salesforce DX, the related Trailhead trail<\/a> is a very good start.<\/p>\r\n\r\n\r\n\r\n Note the versionNumber attribute. Each time you\u2019ll create a new version of your package, the NEXT keyword will automatically increment the build number to the next available for the package. This is pretty convenient.<\/p>\r\n\r\n\r\n\r\n Now that your Package2 is created, let\u2019s create a Package2 Version from your code\u00a0!<\/p>\r\n\r\n\r\n\r\n Let\u2019s stop for a second and add a few notes on what we\u2019ve done.<\/p>\r\n\r\n\r\n\r\n I\u2019ve been using the short version of the flags on the command line, because it\u2019s faster to write.<\/p>\r\n package2id and directory should have the same values as the ones you\u2019ve added to your sfdx-project.json file under \u201cid\u201d and \u201cpath\u201d.<\/p>\r\n\r\n\r\n\r\n All the source code that you have under this path will be used to create the DCP. That\u2019s right, coming from your local code, not from an org\u00a0!<\/p>\r\n Another cool stuff : You won\u2019t have to write a package.xml manifest. Second-Generation Packaging is clever enough to understand what metadata is in the folder (finally!).<\/p>\r\n\r\n\r\n\r\n One last thing to note is the installation key. What\u2019s that\u00a0?<\/p>\r\n Well, something that wasn\u2019t obvious for me when I started playing with DCPs is that they are public. That\u2019s right. Well, you need to know the package id to install it, but still.<\/p>\r\n\r\n\r\n\r\n That may be obvious for you if you\u2019ve been using managed\/unmanaged packages before, but when I started using DCP I was thinking something like DCP=Change Set\/Force.com Migration Tool V2.<\/p>\r\n\r\n\r\n\r\n Your Change Sets can only be installed in the Production org from which the Sandbox was created, and your ant packages are usually stored locally.<\/p>\r\n\r\n\r\n\r\n DCPs are like managed\/unmanaged packages. You can install them via an url (more about this in a second). So you\u2019ll really want to set an installation key if it\u2019s not a open source project.<\/p>\r\n\r\n\r\n\r\n Hopefully you\u2019ll set a more secure installation key in your packages. :)<\/p>\r\n\r\n\r\n\r\n Note that this command is using the \u201cpackage\u201d keyword and not \u201cpackage2\u201d : the install process is the same for all types of packages.<\/p>\r\n\r\n\r\n\r\n That\u2019s it\u2026for installing a package in Scratch Org or Sandbox\u00a0!<\/p>\r\n\r\n\r\n\r\n Production require one additional step.<\/p>\r\n\r\n\r\n\r\n Once you\u2019ve written your code, created Package2 Versions, tested everything at that you\u2019re ready to go to Production, you\u2019ll need to update the version to set it as released.<\/p>\r\n\r\n\r\n\r\n The thing is that in a development lifecycle, you\u2019ll likely create several (hundreds\u00a0?) of Package 2 Versions before being ready to go to Production. Once you\u2019re there, you don\u2019t want to install one of your beta package by mistake.<\/p>\r\n\r\n\r\n\r\n Note that this time you\u2019ll need the Package2 Id starting by 05i (when you create your package version you\u2019ll get 2 Ids, a Package 2 Version Id (starting by 05i) and a Subscriber Package 2 Version Id (starting by 04t)).<\/p>\r\n Don\u2019t worry, you can get all the Ids doing sfdx force:package2:version:list, and every time you\u2019ll do a -h on a command you\u2019ll be told which Id to use.<\/p>\r\n\r\n\r\n\r\n Once your Package2 Version is set as released, you\u2019ll be able to deploy in Production, and voila\u00a0!<\/p>\r\n\r\n\r\n\r\n One last thing you\u2019ll need to do is update you sfdx-project.json file. You can only have one released package per version number (1.0, 1.1\u2026).<\/p>\r\n After creating and deploying our first versions manually using the command line, we then integrated it in our ALM process.<\/p>\r\n\r\n\r\n\r\n A few tips related to this :<\/p>\r\n\r\n\r\n\r\n This will give you commands like this for package creation<\/p>\r\n\r\n\r\n\r\n and installation<\/p>\r\n\r\n\r\n\r\n At the end, we now have a pretty smooth development flow where every developer code \u201clocally\u201d on a Scratch Org, push and merge to the repo when they\u2019re ready.<\/p>\r\n Then the ALM process takes care of everything for us :<\/p>\r\n <\/p>\r\n\r\n\r\n\r\n <\/p>\r\n That\u2019s it ! Should you have any question, please feel free to ask them in the comments or reach out to me on Twitter : @FabienTaillon<\/a>.<\/p>\r\n\r\n\r\n\r\n Update<\/strong><\/p>\r\n<\/blockquote>\r\n\r\n\r\n\r\n Salesforce just released a Trailhead Module and a Quick Start on Unlocked Packages. Seems a good start for everyone curious about DCPs :<\/p>\r\n<\/blockquote>\r\n\r\n\r\n\r\n\r\n
\r\n
Selecting a\u00a0project<\/h2>\r\n\r\n\r\n\r\n
\r\n
Creating a\u00a0Package2<\/h2>\r\n\r\n\r\n\r\n
To create a Package2, just run the following line :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package2:create -n MyPackage -o Unlocked<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nThis will give you a package id (starting with 0Ho) that you\u2019ll need to add to your sfdx-project.json file :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
{<\/pre>\r\n \u201cpath\u201d: \u201cforce-app\u201d,<\/pre>\r\n
\u201cdefault\u201d: true,<\/pre>\r\n
\u201cid\u201d: \u201c0Ho\u2026\u201d,<\/strong><\/pre>\r\n
\u201cversionName\u201d: \u201cv 1.0\u201d,<\/strong><\/pre>\r\n
\u201cversionDescription\u201d: \u201cv1.0\u201d,<\/strong><\/pre>\r\n
\u201cversionNumber\u201d: \u201c1.0.0.NEXT\"<\/strong><\/pre>\r\n
}<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nCreating a Package2\u00a0Version<\/h2>\r\n\r\n\r\n\r\n
Just run the following line :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package2:version:create -i 0Ho\u2026 -d force-app -k mySuperSecretKey<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nYour Package2 Version will be enqueued for creation, and then you\u2019ll be able to run another command to get the status (don\u2019t worry, you\u2019ll get this command line as an output of the previous one, so you\u2019ll just have to copy paste, you lazy developer :P) :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package2:version:get -i 05i\u2026<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nThen I\u2019m used to them, but I could have written the same command with more explicit flag names :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package2:version:create --package2id 0Ho\u2026 --directory force-app --installationkey mySuperSecretKey<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nYou can get help on all CLI commands using -h on them, so running the following will get you all the flags you can use, both in their short and long version :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package2:version:create -h<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nInstalling a Package 2\u00a0Version<\/h2>\r\n\r\n\r\n\r\n
The first way to install a Package2 Version is to simply use an url, like you would do for any existing package :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
https:\/\/login.salesforce.com\/packaging\/installPackage.apexp?p0=04t\u2026<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nIn case you forget the url format, it\u2019s also available through the command line if you list your packages :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package2:version:list<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nThe other option, that you\u2019ll want to use if you automate your deployments, is to install them through a CLI command :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package:install -i 04t\u2026<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nSame as for package2 creation, you\u2019ll be able to query the status of the installation :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package:install:get -i 04t\u2026<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nInstalling a DCP in Production<\/h2>\r\n\r\n\r\n\r\n
Setting a package as released is an easy step :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package2:version:update -i 05i... -s<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nSo just increase the minor version number by one :<\/h4>\r\n\r\n\r\n\r\n
<\/code><\/pre>\r\n\r\n
{<\/pre>\r\n\u201cpath\u201d: \u201cforce-app\u201d,<\/pre>\r\n
\u201cdefault\u201d: true,<\/pre>\r\n
\u201cid\u201d: \u201c0Ho\u2026\u201d,<\/pre>\r\n
\u201cversionName\u201d: \u201cv 1.1<\/strong>\u201d,<\/pre>\r\n
\u201cversionDescription\u201d: \u201cv1.1<\/strong>\u201d,<\/pre>\r\n
\u201cversionNumber\u201d: \u201c1.1<\/strong>.0.NEXT\"<\/pre>\r\n
}<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nUsing Second-Generation Packages in an ALM\u00a0process<\/h2>\r\n\r\n\r\n\r\n
\r\n
<\/code><\/pre>\r\n\r\n
sfdx force:package2:version:create --directory force-app --package2id 0Ho\u2026 --tag 42 --installationkey mySuperSecretKey --wait 30 --json<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\n<\/code><\/pre>\r\n\r\n
sfdx force:package:install --id 04t --installationkey mySuperSecretKey --targetusername myOrg --publishwait 30 --wait 30<\/pre>\r\n<\/blockquote>\r\n
<\/code><\/pre>\r\n\r\n\r\n\r\nDevelopment Flow<\/h2>\r\n\r\n\r\n\r\n
![\"Illustration](\"https:\/\/texei.com\/dev\/wp-content\/uploads\/2018\/03\/1_4Opk9eMK8f0OBx7E18bwqw.png\")
<\/figure>\r\n\r\n\r\n\r\n\r\n
\r\n