Release your app

When your app is ready, validate and publish it to the OCP App Directory. To release it publicly, submit it for review by Optimizely.

For details on preparing, publishing, and installing, see Prepare, publish, and install.

Release options

When you release your app, choose one of the following options:

Normal version – Remove the pre-release tag, such as 1.0.0. The app is publicly available to all Optimizely customers in the App Directory after review approval.
Private version – Use the -private tag, such as 1.0.0-private. The app is released to production, but availability is limited to selected OCP accounts. Use this when you want to release production-ready functionality but control who can install the app. Private versions also require review approval. To install a private version to selected accounts, use the ocp directory install command:
```
ocp directory install [email protected] TRACKER_ID
```

Validate, prepare, publish, and install

Validate your app configuration by running ocp app validate in the CLI.
Run ocp app prepare to prepare your app for publishing. This initiates the code review process. When you run this command with a release version, the CLI prompts you to confirm:
```
You are uploading a release version of the app. This will start a review process and the app can't be published until it is approved. Are you sure?
```
Enter yes to proceed. When your app is approved (review takes one to two business days), proceed to step 3.
Publish the app to the OCP App Directory by running ocp directory publish [email protected]. See App versioning for details on versioning your app.
Run ocp directory install [email protected] TRACKER_ID to install the app into your OCP account. Replace TRACKER_ID with your OCP account tracker ID. For example, ocp directory install [email protected] Z6jCndly_E2WzpvDkcKBKA.

View your app listing in the OCP App Directory.

App review process

📘
Note
The app review process typically takes one to two business days to complete.

Running the ocp app prepare command with normal, beta, or private versions initiates the app review process.

The Optimizely App Review team invites you to a GitHub repository containing your app code. When you accept the invitation, you can see the pull request and feedback from Optimizely engineers as they review your code.

📘
Note
GitHub notifies you by email about any activity in your app review repository.

If Optimizely determines that changes are required, Optimizely submits a GitHub pull request. After you make the requested changes, run ocp app prepare in the OCP CLI again with the same version. This updates the pull request with the latest code from your app.

This review ensures your app meets design guidelines, content guidelines, and security requirements so customers can safely use your app.

Best practices

Your app should meet the following guidelines before you submit it for review:

Security

Your app cannot contain any secrets or credentials. Store secrets in environment variables, in a .env file outside of GitHub.
Your app cannot log secrets or credentials.
The .env file cannot be part of the repository.
Your app cannot import PII data.
Your app cannot scan the engine code or invoke internal engine code other than through the API defined in the App SDK.
Your app cannot execute any OS commands directly.
Your app cannot gather, log, or send any information about how the runtime is built (OS version, folder structure, networking, ports, and so on).

app.yml

Your app must accurately identify itself in the metadata section. The app_id, display_name, and summary should clearly identify the app and its purpose.
All URLs you define in the metadata must be valid, functioning URLs.
Define the partner developing the app in the vendor field.

Jobs

The perform method should complete in under 60 seconds.
The prepare method should handle initializing and resuming the job.

Logging

Use logger for logging, not console.

src/schema

Prefix all objects and fields unique to your app with your app ID.

Storage

Your app cannot store data outside of OCP. Use available storage instead.
Only store secrets in the secrets store.

Track your app review in GitHub

When you submit your app for review, GitHub sends you an email inviting you to your app's repository in Optimizely-Connector-Platform-AppReview. Accept the invitation to participate in the review. GitHub notifies you each time Optimizely comments on your review or requests changes.

Communicate directly with the reviewers in GitHub throughout the review process.

Check review status in the OCP CLI

Run the following command in the OCP CLI to view your app's review status:

ocp directory status APP_REVIEW_ID@APP_VERSION

Open GitHub review from the OCP CLI

Run the following command in the OCP CLI to open the GitHub review in your browser:

ocp review open APP_REVIEW_ID@APP_VERSION

Change requests during app review

During the review, Optimizely may submit change requests through GitHub. To make the requested changes:

Change the version of your app in app.yml back to a dev version by adding the -dev tag. For example, if the app version you submitted for review was 0.0.1, change it to 0.0.1-dev.1.
📘
Note
Maintain the same version number (for example, 0.0.1) throughout the review. Changing the version number creates a new review repository.
Make the requested changes, then test your app internally with the -dev tag.
Remove the -dev tag from the version in app.yml.
Run the following command in the OCP CLI to resubmit your app to the existing review:
```
ocp app prepare
```

Continue monitoring the review in GitHub and making the requested changes until your app is approved.

Release publicly

When Optimizely approves your app, run the following command in the OCP CLI to release your app publicly:

ocp directory publish [email protected]

Your app is then available in the OCP App Directory for all Optimizely customers.

Versioning after release

After your initial release, publish updates using the same versioning scheme:

PATCH versions like 1.0.1 – Bug fixes that require a review.
MINOR versions like 1.1.0 – Feature additions that auto-upgrade existing installations after review approval.
MAJOR versions like 2.0.0 – Breaking changes that require a review.

See App versioning for details on how OCP handles version upgrades and the -dev workflow.