Managing the Application Lifecycle

Having a proper application lifecycle enables you to have a proper framework for managing and deploying applications. This includes managing user access to resources, building and deploying applications, and application monitoring. This article covers how you can manage the application lifecycle for your applications.

Publishing Strategy

When looking to publish and deploy an application, there are four different stages that your application should move across:

• App Preview

• DEV

• QA

• PROD

App Preview can be considered your local environment. This is where you are able to emulate your application and test every interaction and channel your users take. The App Preview also provides event and state viewers that allow you to see the state and accessible data for each event that occurs in the app. This is a non-shareable environment and is meant for the developer to fully test out an application before publishing to a DEV environment.

When ready to publish, you’d want to configure all the integrations, resources, data, etc. with the DEV published instance and publish to the DEV environment. When you are done building out your app and ready to move onto the testing phase, you can then publish the DEV deployment to your QA environment. This process is very similar to publishing to DEV, where you will need to configure all the integrations, resources, data, etc with the QA published instance.

Once your application has been thoroughly tested and ready to move for deployment, you can then publish your application to the PROD environment. Again, this requires you to configure all the integrations, resources, data, etc. with the published instance.

For example, if you are using a custom domain for your applications, you’d have three separate custom domains that you’d need to set up the CNAME for each environment:

• form-dev.airco.com (DEV)

• form-qa.airco.com (QA)

• form.airco.com (PROD)

This concept of separating resources per environment and configuring them for the respective published app instance allows you to control access and certain users to the resources and the apps associated.

Hotfixes

Sometimes you will find a bug in your application that has been pushed to the PROD environment and that you will need to hotfix. You have two options here:

• Fix it locally and push it to DEV -> QA -> PROD. This approach falls into the category of an update, rather than a hotfix.

• Take a copy of the PROD deployment and then make an editable branch to make fixes, and republish. This approach falls more in line with a hotfix.

If you plan on using the second option, there are a few things that need to be considered. This approach is bypassing the standard approach of updating your application, which means that any changes you make in PROD will have to be copied across the other environments. A change in just the PROD environment does not reflect across DEV and QA. Another consideration is that in order to make a hotfix, you must have access to that environment as well. A developer who only has access to the DEV environment cannot make changes in PROD.

Environments and Access Control

In order to publish and configure resources across the different environments, you will need to have the proper permissions for that environment. For more information, see Custom Roles - Role Based Access Control (RBAC)

Application monitoring

Once your application is deployed, interactions with it are logged as Session Events. Many Session Events, such as how many Journeys are currently active or when a particular Action Chain is fired, are logged automatically. It is also possible to define Custom Events through the Log Custom Event Action. Custom Events will be logged the same way as any other Event, and they are accessible through the same means.

Accessing Journey Data

Journey data can be viewed directly in the Activity Builder, which can be found in the Console. Journey data can also be sent to external analytics platforms, where it can be analyzed as well as viewed. See Analytics Overview for a more comprehensive discussion of the various integrations Airkit supports with external analytics platforms.

Activity Explorer

Activity Explorer provides a way to view the Events that occur on a session to help troubleshoot and diagnose issues within an application. The Activity Explorer surfaces every Journey that occurs in a published application and logs every Event and key activity from the user within that Journey and is useful for debugging specific sessions if any errors occur. For more information on Activity Explorer, see View Journey Data.

Snowflake Secure Data Sharing

[block:callout] { "type": "info", "body": "This feature requires an ENTERPRISE license. If you would like to enable this feature for your Airkit Organization, please contact your Airkit representative or contact [e-mail]." } [/block] Data collected in your Airkit Organization can be securely shared using Snowflake's Secure Data Sharing. For more on how this raw data is stored and structured, see Snowflake Analytics Schema.

Streaming to AWS S3 buckets.

App Events and Audit logs can be streamed from Airkit to AWS S3 buckets. These Events and logs help provide insight into your Airkit apps and logs within your Airkit Organization. For more on how to configure this, see App Events to AWS S3 Buckets and Audit Logs to AWS S3 Buckets.

Sending Notifiers

App Errors and Custom Errors can be surfaced and sent as notifiers to developers to monitor their applications. You can use the out of the box Notifiers to send Application Errors or you can create custom event errors using the Log Custom Event Action.

See Integrating Error Notifications to Slack for more information on App notifiers and Logging Custom Event Errors for more information on sending alert notifications when Custom Event Errors are fired.