Get ready for Production

This article is an overview of aspects to consider when moving from Development Environment to Test or Production environment.

Testing in a non-develop Environment

Testing in either a Test environment or in Production environment must be done prior to full release.

Verify Security and Permissions

As part of Testing, you will realize that Security must be considered when moving from Develop to Test.

Go through the Security checklist.

Verify User Handling

Depending on your approach to adding new Users to your Apps, you should test adding new Users to your Test environment, and actually log in with these Users. Use an alias email or another email than your Create-User.

Tip: If you have a Google account, you may add email aliases on-the-go. If your email address is [e-mail] you can create a User Account with email [e-mail], and the pin-code or reset password email will be sent to your [e-mail] inbox.

Verify initial Data

You may need to create some Data or import some data in your other environments. For example, you might have imported a Countries list in your Dev environment. These data need to be imported into Test or Prod environments as well.

Performance control

Probably not an issue to begin with, if your App does not hold much Data initially. But as time goes, the database will increase in size - so might the number of records in your Data Source.

Please go through the Optimization section for some possible performance issues, and how to solve them.

Verify links for external integrations

If your app has integration towards other systems, the URL towards the other system usually differ between Dev/Test and Production.

A good practice is to store the hostname of the external endpoint as a Secret, and make the Secret Environment Specific. You may use the Secret in your Web Request, instead of hard-coding an URL. Read more on Secrets here, or as part of our Web Request.

Verify links used in Send Email and Send SMS

If your app has action for sending Emails or SMS, the content often holds links for the user to click. Make sure these are not hard-coded to your DEV-environment.

A good practice is to use the built-in property App Variables.Hostname. This variable holds the hostname of your solution for the environment you are running the client in. For example, when opening https://showroom.appfarm.app, App Variables.Hostname will hold showroom.appfarm.app. But when opening Showroom in DEV environment, the variable will hold showroom-dev.appfarm.app.

Testing with real users

Let some real end-users do some testing of your application. Both for the sake of verifying the flow and logic from someone who has not clicked the button in the exact same order as you do while developing, but also for fixing the most common bugs. All applications have bugs or missing functionality when only tested by yourself.

Soft Launch in Production

Depending on the amount of testing by real end-users in a Test environment, it might be a good idea to launch your solution in production with only a few real end-user for a short initial period.

Technically, if testing succeeds in Test environment, most aspects of security and environment configuration have already been tested. The biggest hurdle is when moving from Develop to either Test or Production. However, some initial testing should be done in Production as well.

Custom URL in Production?

Appfarm offers customers to have a custom domain in production environment, as opposed to the default (https://{SOLUTION_SHORTNAME}.appfarm.app). This must be configured by the Appfarm Team. Please make contact if this is relevant.