When Launch was still in the planning phases and we were first figuring out how extensions would work, we realized that Launch users were going to want to have private extensions. Private extensions can be installed and used on a property like any other extension, but they are only available within the company that owns the extension. Nobody else can see it.
In order to deliver this feature, we need to make a few tweaks to the way that Extension Developers test their extensions prior to release. These changes will put you as developers in full control of the lifecycle of your Launch extension.
If you are (or want to be) a Launch extension developer, please keep reading for some important info. Also, please come join fellow extension developers and members of the Launch engineering team in the Launch Developers Slack workspace (click here to join).
If you're a Launch user who is anxious to use Private extensions, stay tuned for updates, the Release Notes will probably your first indicator.
If you read this and still have questions about Private Extensions, you're probably not alone. Please post your questions below and I'll make sure they get answered.
Happy extension building 😃
1) Release Timeline
We're planning on releasing this feature into the Integration environment on Thursday, October 18. From that point forward, you'll need to follow the new process for testing outlined below.
We want you to be able to test these changes in Integration for a few weeks before we put them in Production. We plan to release this into Production in the first few weeks of November, the exact date is still TBD. Once this has been done, we will no longer be the gatekeepers of your extensions, you will take full ownership of testing your extensions, determining when they are ready for release, and releasing them. We will continue to be available to answer questions and assist as needed.
At some future date - probably a few months from now, after the dust has settled - we'll likely decommission the Integration environment as your end-to-end testing workflow will be fully supported in the production environment.
2) Changes You Need to Know About
Before I go into specifics and outline the new testing process, I want to first describe the specific changes that will be made.
2.1) New "Develop Extensions" Permission
Currently, the ability to upload an extension is granted to individual users explicitly by a member of the Launch team. With the release of private extensions, you will now be able to control this process on your own.
The recommended path is to create an Adobe I/O Integration - also called a technical account - with the Extension Developer role. Otherwise your technical account will not be authorized to upload extensions. You can create new Integrations with this role or update existing Integrations to use this role.
Any users or technical accounts in your Org that have this right will be able to manage all extensions which are owned by your Org.
When you upload your .zip file to Launch, Launch creates an extension_package resource to represent that package. This is different from an extension, which represents an instance of that extension_package actually installed on a property.
An extension_package now has an attribute called `availability` that determines which properties can install and use this extension_package. When you POST an extension_package, this attribute will be set to "development" automatically. After you have completed testing (more on that below), you'll PATCH the extension package to change the `availability` to "private".
A "private"package represents the new capability that this extension_package should only be available for installation on properties within this same company.
Once you have released an extension_package privately, you can request that Adobe release it publicly. A "public" package represents the existing capability for that extension to be available in the public catalog. The Public Release Request Form is available now.
2.3) Development Properties
When you create a new Property, you'll now have an option to create a Development property. These behave exactly the same as a regular property with one exception. Development properties can see, install, and use extension_packages that have availability of "development".
Inside a Development property, a Development extension behaves exactly as a regular extension.
You'll need to create at least one Development property in order to test your extensions.
2.4) Owning Org
Extension_packages now have an attribute for the `owning_org`. This is the IMS Organization ID of the company that owns the extension_package. You do not have to fill this out, it will be done for you automatically based on your Active Org at the time of upload.
For technical accounts, this will be taken care of for you.
We will backfill this information for existing extension_packages in the Integration environment, but we're only human. When we make mistakes, you'll lose access to PATCH your extension_package. If this happens to you, please reach out to us in the Launch Developers Slack workspace (click here to join) and let us know. We'll get you taken care of.
When we release private extensions into the Production environment, we will port ownership from the Integration environment to Production.
3) New Testing Process
With these important changes detailed, I can now describe the testing process, some of the failure scenarios when things go wrong, and what you can do to fix things.
3.1) Happy Path Testing
First, you'll need to update your permissions. For user accounts you get this for free in Integration. For technical accounts, login to https://console.adobe.io and update your Integration to use the Extension Developer role.
Within your Development property, go to the Launch catalog and install your extension.
Make resources, add them to libraries, deploy builds, and test. This will look different depending on what your extension is doing.
If you need to make updates to your extension:
PATCH your extension_package
Update your resources
Make new builds
Rinse & repeat
When you are sure your extension is ready to go, you can transition your extension_package to private or public.
Once you have transitioned your extension_package to private, that version is immutable and the only way to make changes is to POST a new development version and transition it up.
Private extension_packages can be made public, but that cannot happen in reverse. Neither public or private packages can be transitioned back to development.
3.2) Failure States
As you develop, you'll most likely end up with extension_packages that do not succeed. Your package won't pass validation, you'll leave something out of extension.json, etc. Here are a few things to watch out for. The images are mocks. Final version will likely look different, but should give you a good idea of what to expect.
When you first upload an extension_package, initial validation is performed before it becomes available for installation. If you happen to view the Launch catalog while your extension_package is still being processed, you'll see an extension card with a Pending label on it. Launch will provide the ID of the package on the card.
3.2.2) Failed Package
If you've had a successful extension_package, but then PATCH it to make updates and the update fails, you'll see an extension card with a Failed label on it. Launch will provide you with the name, ID, and failure message so you can fix the issue and PATCH it again.
3.2.3) Property with Failed Package
It's also possible to install an extension to a development property, then PATCH the extension_package to make updates and have the update fail. This means your installed extension is now linked to a Failed package. When you attempt to work with this development property, you'll find an error page with information about any extensions with failed extension packages and you'll need to restore your extension_package to a working state before you can continue working with that property.
4) Update on Release Public11/2
We had some discussions with our new colleagues from Magento about their marketplace. After those discussions, we've believe it is the everyone's best interest if we have some level of curation in the extension catalog. As a result, we've made the decision to limit access to the public release API until we have a chance to do some more product work in that area.
The post above has been updated, but the basics of the changes are:
In order to do a public release, you must first do a private release (making the extension available to your own company)