We are always looking to be on the cutting edge of technology here at CRM Science in both what we provide to our customers and how we provide it to them. Our most recent offering on the AppExchange is the CRM Science AI Lab. It helps anyone leverage the power of Einstien.ai using an admin-friendly UI. But the project also showcased another new milestone for the lab coat team that the end user would not even notice.
It was our first application fully developed using Salesforce DX!
We used the AI Lab project to evaluate the new DX tools during the feature beta release in Summer ‘17. Our selected team of developers found it to be a great improvement over previous offerings. Now that DX has gone GA, we will be expanding the rollout to the additional teams to begin use on more AppExchange offerings and Enterprise solutions.
But we are already looking for the next big thing to assist us in Salesforce development, and we suspect that next big thing will be Packaging 2. We have started experimenting with it during its beta Winter ‘18 release. Here are some of our initial thoughts.
Goodbye Packaging Orgs, Hello CLI
The first major change in Packaging 2 is that it is done entirely in the Command Line Interface introduced with Salesforce DX.
In the current generation of packaging, teams would have to develop in a single developer org that was associated with the package’s namespace. When it is time to release a beta or regular version of the package, a user would have to log into the org and navigate through the UI to perform the upload and obtain an install link.
Fortunately for current generation packaging users, Salesforce DX already introduces some Packaging 1 functions in the CLI to help with this process. For our CRM Science AI Lab project, we created a script in our repository pipeline to automatically upload to our packaging, release a beta version, and obtain a package ID every time we merge code into our master branch. This change has already saved us many of man hours going through the UI every time we want to release a beta.
But when it comes to Packaging 2, there is no need to maintain code in any development org at all. In fact, once you establish a namespace and add it to your company’s development hub, you will never have to log into that developer org again. The rest is left to your DX CLI.
Packaging 2 provides new CLI commands to create new packages, create new package beta versions based on your DX project, then mark beta versions as “released” when they are ready to ship. All the information is stored in your company’s dev hub and can be easily viewed by your co-worker on their own DX environments.
These additional commands allow for more options in automating the maintenance of packages. The more work that can be thrown into automation, the more time your developers will have to focus on creating the best application for your use.
Multiple Packages, One Namespace
The potential game-changing feature in Packaging 2 is the ability to create multiple packages in the same namespace.
This idea might be a little hard for current Salesforce developers to wrap their heads around. We have been used to one simple rule - each managed package has its own namespace, and that namespace belongs to only that package.
But what happens when you need to build an extension to that package? Your client loves the package you are selling on the AppExchange, but they just need one little customization to it to help their particular business needs. If you build a second package to work with the first one, it would have to have a different namespace and would not have access to the contents of the first package. This makes it very difficult to create these minor extensions.
Most developers work around this limitation by building global functions into their base package and having the extension communicate with it through those methods. However, when you expose global methods, you expose it to everyone. So anyone would be able to call into your base package, which could have unwanted consequences to your app.
But thanks to Packaging 2, you can create as many packages as you want under the same namespace. You can even install multiple packages in the same org with the same namespace. This means that those packages will be able to communicate with each other using “public” methods. All of your code will continue to be secure behind your namespace while you now have the flexibility to install exactly what you need for any particular client.
Packaging Brings DX to Your Enterprise Solution
The biggest hurdle that Salesforce developers encounter when switching from sandbox development to DX is that DX requires the developer to break down their entire Enterprise org into individual projects. This is a daunting task because these orgs have spent many years of development without such modularization, so they are unlikely to present an easy way break apart for the sake of easy maintainability.
At CRM Science, we understand that this is a very difficult transition, and we have often used first generation packaging as a metaphor of how to approach it. A Salesforce DX project is like an unmanaged package. DX projects are developed in an environment similar to a developer packaging org so that they remain independent from any dependencies in the Enterprise org. When you are ready to deploy your project into a sandbox or your production org, the Metadata API deployment is similar to installing that unmanaged package as opposed to using change sets. If you can break your current solution into a series of packages, you can begin to use Salesforce DX to better manage your Enterprise solution.
However, Salesforce has been specifically avoided using the word “packaging” to describe DX modularization for now. The reason for this is because Packaging 2 will actually make this metaphor into the standard for Enterprise development. Your development and deployment strategy will be completely based on packages.
This new feature is called “Developer-Controlled Packaging” and it is currently in pilot for the Winter ‘18 release. This new feature comes in two flavors:
The first type of Developer-Controlled Packaging is unlocked packages. These work similarly to deploying changesets to your Production org. Admins will have the ability to modify certain assets such as custom fields or Visualforce pages. But the package is the source of truth, and all those changes will be overwritten once the new package is installed.
To prevent your admins from modifying your work, you can release the other type of package to your production org - the locked package. The contents of the locked package can not be modified by admins, leaving it entirely in the control of your development team. This is very similar to using managed packages today, but with much more flexibility for the developer to add or remove content in the future.
Developer-Controlled Packaging does not fix the issue of breaking your current org into modular components. Unfortunately, that is still a task that will have to be completed by your development team or left as is for now. However, it will set new standard practices for your developers to ensure that all your future projects will be modular, which will make your Enterprise org a lot easier to maintain and build on.
Packaging 2 has us excited at CRM Science, and we will continue to evaluate it during its beta period up until it is ready for GA. We are already setting up brand new automated processes to maintain and release new packages to you faster than ever. We look forward to offering better custom extensions on our products to all of our customers. And we will be happy to assist you in setting a new best practice for development and deployment strategy to your Enterprise solution.
Additional Resources
Release Notes: Imagine What You Can Do with Second-Generation Packaging
Developer Documentation: Develop Second-Generation Packages
