search

alan-ai / alan-sdk-ionic

Conversational AI SDK for Ionic to enable text and voice conversations with actions (React, Angular, Vue)
https://alan.app
1.69k stars 18 forks source link

Tips on handling production releases #26

Closed ljudbane closed 2 years ago

ljudbane commented 2 years ago

Hello.

I have a question regarding handling production releases. What is your "best practice" or advice when releasing new production versions?

For example we release a mobile app with Alan SDK key xxxx/prod and we select a v1 version of Alan scripts on production environment. So now users can use the mobile app with v1 alan scripts.

Then we continue development and create a v2 of Alan scripts which is compatible with the next release/version of our mobile app. Then we release the new version of mobile app. In this moment we have users with old version of the app and users who have upgraded the app to new version. If we change Alan production environment to v2 scripts, the new app will work ok, but now the old version of the app will also use v2 alan scripts, which can be incompatible. For some time, until all users update their mobile app, we should support 2 versions of alan scripts (probably more if we don't force users to update app).

How do you recommend to tackle this issue? Should this be handled in scripts/code or with some project settings?

aermilin commented 2 years ago

Hello,

Alan SDK is not different from any other SDK and you can use the following strategies:

  1. You can use Project API (https://alan.app/docs/server-api/sending-data/project-api/) to send app version to the script. You will store this data in a user-scope variable (i.e. p.userData.version). After initializing Alan button just call the Project API and pass version as a param. Now you can control the behaviour of your script by a simple if-then statement when you need to differ commands or other script logic depending on the app version.

  2. If you have drastically changed the script logic between v1 and v2 versions - you can consider creating another project for users of v2 app. When preparing to rollout v2 version of the app - just change your old project key to a new one. Now users with v1 app will connect to the old project with v1 scripts and v2 app users will connect to the new project with v2 scripts.

  3. The most advanced strategy is to use visual state (https://alan.app/docs/server-api/sending-data/visual-state/) to pass the version or some special logic identifier to the script. What is the difference between Visual State and Project Api? It comes with the major advantage - Visual State allows you not only to differ the logic after intent activation (https://alan.app/docs/server-api/sending-data/visual-state/#differentiating-the-command-logic), but also to filter what intents are available through visual filters feature (https://alan.app/docs/server-api/sending-data/visual-state/#filtering-commands). So if you have some new intents that will only work in v2 and want to make them unavailable for v1 app users while having all users/statistics/analytics in one project - Visual State is your best solution. Take note that Visual State is dynamic and will be completely overwritten when you call setVisualState. So every time you send a new visual state object for other task/logic in your app you will have to include app version in it.