Deployment Overview
The CLI provides out-of-the-box features for developers to manage the lifecycle of their App Builder Applications. This documentation focuses on the application deployment step of this lifecycle.
Setup Assumptions
In the following chapters of this documentation, it will be assumed that:
The Custom Adobe Application has been bootstrapped from a generator using the CLI
There is a .env file at the root of the application folder, which contains the following keys and their values:
- AIO_RUNTIME_AUTH, which holds the credentials for the Runtime namespace to use
- AIO_RUNTIME_NAMESPACE, which holds the name of the Runtime namespace to use
If you do not own a Runtime namespace, please request trial access.
The Setup Requirements documentation should also be checked before trying out the deployment scenarios described below.
The CLI offers three types of deployment to the developers.
Local Deployment
Local deployment capabilities are offered to developers who want to test and debug their application before this one gets deployed to the out-of-the-box Content Delivery Network.
Local Runtime actions and UI
Use-Case
This local deployment feature is useful for developers who want to easily get an initial preview of their Custom Application before deploying it to Runtime and to the out-of-the-box Content Delivery Network. They will also benefit from local Runtime actions and UI debugging capabilities.
It also helps developers who want to work on their Custom Application implementation without an appropriate Internet connection. Of course, in that case you are not able to interact with Adobe APIs or with remote 3rd party systems.
The tradeoff is that developers will not be able to run code that uses Files or State SDKs, cron jobs scheduler with Alarms package, as well as expose web actions as webhooks for I/O Events or external events providers. These are only available if the actions are deployed to Runtime.
This deployment scenario doesn't require any specific credentials, as both Runtime actions and application UI are hosted on the developer's machine.
CLI Command
This deployment is triggered when running aio app run --local at the root of the Custom Application source code directory.
Architecture
In this scenario, the CLI will download a standalone instance of Apache OpenWhisk, which is the open source serverless platform behind Runtime, on the developer's machine.
The Runtime actions of the application will be deployed to this local Apache OpenWhisk instance, and executed in NodeJS docker containers spinned up locally from the Docker images that are documented in the Technical Prerequisites section above.
The local Apache OpenWhisk instance runs on port 3233 by default, and the deployed actions will be accessible at:
Copied to your clipboardhttp://localhost:3233/api/v1/web/guest/<appname-appversion>/<action-name>
appname and appversion are both application name and version, which are maintained in the package.json file at the root of the Custom Application source code folder.
action-name is the name of the action, which has been chosen by the developer when bootstrapping the application from the generator that was executed with aio app init <appname>.
In case of a headful Custom Application, the UI will be served locally from ParcelJS, which is the underlying framework used by the CLI to build the front-end source code.
Remote Runtime actions and local UI
Technical Prerequisites
This deployment scenario requires Runtime credentials in a .env file at the root of the Custom Application source code folder, as documented in the Setup Assumptions above.
Use-Case
This feature is useful for developers who want to test and debug locally their Custom Application in a live environment fully integrated to Adobe's ecosystem, with minimal deployment time and efforts.
CLI Command
This deployment is triggered when running aio app run at the root of the Custom Application source code directory.
Architecture
The UI is still served locally from ParcelJS, which allows hot updates of the front-end code. It communicates with Runtime actions deployed to the developer's Runtime namespace.
Full Deployment
Technical Prerequisites
This deployment scenario requires Runtime credentials in a .env file at the root of the Custom Application source code folder, as documented in the Setup Assumptions above.
Use-Case
This feature is useful for developers who want to test and preview their Custom Application fully integrated to Adobe's ecosystem, in conditions that are similar to a production deployment.
CLI Command
This deployment is triggered when running aio app deploy at the root of the Custom Application source code directory.
Architecture
The UI is deployed to the out-of-the-box content Content Delivery Network on behalf of the developer's Runtime credentials. It communicates with Runtime actions deployed to the developer's Runtime namespace.
The out-of-the-box Token-Vending Machine is implicitely used by the CLI aio app deploy command, and validates the developer's Runtime credentials against Runtime.
If the credentials are valid, the Token-Vending Machine provides an access token to the CLI, which will authorize the CLI to deploy the static files of the Custom Application to the Content Delivery Network.
The deployed Custom Application will then be available at https://<namespace>.adobeio-static.net/<appname>-<appversion>/index.html, where namespace is the developer's namespace, appname and appversion are respectively the Custom Application name and version, which are maintained in the package.json file at the root of the Custom Application source code folder.
