CI/CD for App Builder Applications

Continuous integration and continuous delivery (CI/CD) is a crucial component for the success of any development team -- a team working on App Builder Applications is no difference. Allowing the development team to focus on requirements, code quality, and security with deployment automated, CI/CD is one of the best practice to implement and for us to support.

App Builder allows you to manage multiple environments. This is achieved through Workspace in Adobe Developer Console. Every new application project created by an entitled organization administrator or developer in the Developer Console will be setup with two named workspaces: Stage and Production. Each workspace will have its own setup:

• List of Adobe services to integrate via user or technical user accounts
• Runtime namespace
• Cloud storage for the SPA static files
• CDN delegation and sub-domain provisioned on adobeio-static.net
• Related credentials and secrets (API Key, access token, Runtime namespace credentials...)

The entitled organization users will also be allowed to create as many additional workspaces as required by their project, whether this is to add an extra stage (e.g. qa, preproduction...) to match their infrastructure needs, or to define developer specific workspaces for each of their development team member to work locally against.

Local Application Development

In your project, there could be several developers working on the same application code. They may clone the code from the same branch, or create different branches for new features, but the deployments should all be different so that they do not interfere each other. Each developer is able to use individual workspaces described above to create their own deployment.

The pre-requisites are, application code already cloned to the local machine, and the workspace config JSON file that is downloaded from Adobe Developer Console. Then in the terminal, navigate to the home directory of the application code and run this command:

Copy
aio app use path/to/workspace.json
Copied to your clipboard
aio app use path/to/workspace.json

You can then check if the workspace is set up for the app by verifying the .aio and .env files, which contain the target workspace details.

GitHub Actions Support

A sample CI/CD workflow is provided out-of-the-box on top of GitHub Actions. Upon bootstrapping of a new App Builder Application from the CLI by using the aio app init command, the application generator asks the developer whether to include GitHub Actions based workflows for Build, Test and Deploy.

If the developer selects this option, the application code will be initialized with an additional .github folder at its root. This folder contains default GitHub Workflows that can be extended at application level depending on the developer's needs.

Github Workflows

The default GitHub Workflows enable the following actions based on specific Github events triggered on the application repository:

• On Pull Request, the application unit tests are executed by calling aio app test against the requested changes. See the PR workflow.

• On Branch Merge, the application gets deployed to the Stage workspace by calling aio app deploy. The back-end serverless actions get deployed to Runtime, while the SPA gets deployed to the out-of-the-box CDN if the application has a web UI. See the Deploy Stage workflow.

• On Repository Release, the application gets deployed to the Production workspace by calling aio app deploy. The back-end serverless actions get deployed to Runtime, while the SPA gets deployed to the out-of-the-box CDN if the application has a web UI. See the Deploy Prod workflow.

Each of the default Github Workflows leverages two core features provided by Github: Github Actions and Github Secrets.

GitHub Actions for AIO CLI

The following GitHub Actions have been built to support the usage of the CLI in a CI/CD workflow running within GitHub infrastructure.

They are used in the default App Builder Apps workflows, but can also be used further in custom GitHub workflows built by developers to fulfil their project needs.

• The CLI Setup Action can be used to install and configure the CLI on the GitHub infrastructure running the workflow that invoked the action.

• The Apps Action centralizes the support for a GitHub workflow to leverage several application specific commands, such as testing via aio app test and deployment via aio app deploy.

These both actions have been published and can be found on GitHub Marketplace. See CLI Setup and Apps.

GitHub Secrets

The following GitHub Actions leverage GitHub Secrets to store environment specific secrets.

They currently need an administrator to manually add the following secrets to the application repository:

• AIO_RUNTIME_NAMESPACE_STAGE: the name of the Runtime namespace associated to the Stage App Builder workspace.
• AIO_RUNTIME_AUTH_STAGE: the credentials for the Runtime namespace associated to the Stage App Builder workspace.
• AIO_RUNTIME_NAMESPACE_PROD: the name of the Runtime namespace associated to the Prod App Builder workspace.
• AIO_RUNTIME_AUTH_PROD: the credentials for the Runtime namespace associated to the Prod App Builder workspace.

We aim to simplify this configuration process in the future.

Bring your own CI/CD pipeline

The default implementation of the CI/CD workflow for App Builder Applications relies on GitHub capabilities. However, a developer might need an alternative solution due to project specific requirements, or team preference.

In that case, we recommend implementing the custom solution with focus on two main aspects:

• The CLI is the official tool to manage the App Builder Application development lifecycle from bootstrapping to deployment, and can be used within a CI/CD workflow for automation purpose.
• Security is a key requirement, and any alternative CI/CD workflow should propose a solid secret management solution to store the credentials required to deploy an App Builder Application against a specific Workspace.

Last updated 5/21/2024

Was this helpful?

Yes

No