Deploy
Deploy your apps and services to Test, Staging and Production. View the Solution deploy history, and manage Snapshots.
Last updated
Was this helpful?
Deploy your apps and services to Test, Staging and Production. View the Solution deploy history, and manage Snapshots.
Last updated
Was this helpful?
Appfarm Create has one-click deploy, so that you can push your apps and services to Production with one click of the big blue button. Deploys to the Development environment are instant and the Appfarm Client will hot reload by default. You can also revert deployed changes through the use of Snapshots and rollbacks.
Up to four deployment environments are available. The environments available in your Solution depend on your subscription agreement. The environments are:
Development
https://{SOLUTION_SHORTNAME}-dev.appfarm.app
Instant deploys and with its own database. For Appfarm developers only.
Test
https://{SOLUTION_SHORTNAME}-test.appfarm.app
A sandbox for non-developers to test in, with its own database.
Staging
https://{SOLUTION_SHORTNAME}-stage.appfarm.app
A final testing ground before Production. Uses the Production database.
Production
https://{SOLUTION_SHORTNAME}.appfarm.app
The live environment for your end-users.
Important
The Staging environment uses the Production database. Any changes made to data in Staging will be reflected in Production.
Users exist across all environments. For example, a user created in Production can be deleted in Test. See Users for more details.
The big blue deploy button will be active if there are changes to be deployed from one environment to the next. Click this button to open the Deploy dialog. If the deploy button is disabled, there are no changes to deploy.
Appfarm supports two type of deploys, Solution deploy and Targeted deploy. Targeted deploy is in beta and the vast majority of solutions only have access to Solution deploy.
Solution deploys are sequential across environments, so you must first deploy to Test and Staging (if they are active in your solution) before deploying to Production. All changes in a given environment are deployed to the next.
The solution deploy dialog is shown in the image below.
This alert will appear if the deploy will result in an upgrade of the Appfarm Client. This process takes just a few minutes and ensures the latest features and bug fixes are applied in the environment.
Select when to deploy. By choosing Other, a specific time can be set.
Optionally provide a custom deploy message to show users alongside the default deploy message. The default deploy message is: "New version available A new version of {APP NAME} is ready. Please press reload to get the new version."
Optionally include your avatar and name with the deploy message to give it a more personal touch.
Optionally, you can provide an internal note to display in Appfarm Create's deploy history. This is useful for tracking changes across deployments.
Click to open the deploy changelog to get a comprehensive overview of the changes to be deployed.
Click to deploy changes and platform upgrades to the next environment.
Targeted deploy allows developers to deploy selected changes directly to selected environments. For instance, a change can be deployed directly to Production without interrupting ongoing testing in the Test environment. Four types of deployable "units" can be deployed independently of other changes in the environment:
Apps
Themes
Schedules
Services
Appfarm Create automatically calculates dependencies when deploying selected changes. For example, if changes to an app are deployed and this app uses a new object class, the new object class will also be deployed.
The targeted deploy dialog is shown in the image below.
Select which environment to deploy changes to.
Choose whether to deploy all or selected changes from the current environment.
Select which deployable units to deploy. Only units with deployable changes will appear in this list. This list is only visible if Selected changes from Develop is selected.
Information about additional dependencies that will be deployed based on the selected changes.
Click to show a detailed changelog of the selected changes.
Only entities affected by the deploy will hot reload when deploying selected changes. For example, if there are two apps in the solution and changes are only deployed to one, users of the other app will not be affected.
If you have undeployed changes in an environment you can view a list of what has changed. Click Change Details to see an overview of:
New apps and services
New and changed actions, data sources and views by app/service
New and changed themes and schedules
New and changed enums and object classes
Number of deleted apps and services
Number of deleted actions, data sources, and views
Number of deleted themes and schedules
Number of deleted enums and object classes
Appfarm Create is frequently upgraded with new releases with both major and minor updates.
Appfarm is responsible for thorough testing of new versions before Appfarm Create is upgraded, but when such upgrades occur the next deployment for all Solutions will be affected.
In the example above, Appfarm Create has been upgraded to Appfarm Version 22-4-33. When Appfarm Create has been upgraded, so has your Develop environment (the client). The Test and Production environments, however, are still on version 22-4-32. The next deployment from Dev to Test will automatically upgrade Test environment to 22-4-33 as well.
Appfarm Upgrades are mandatory and cannot be removed from the Deploy. The reason is that they may contain important bug fixes, or new Appfarm features that require new Appfarm code.
Note that such upgrades of the Test or Production environment are only experienced as an information dialog followed by a refresh for the end user. But we recommend to schedule such deploys to midnight.
A snapshot is a copy of your solution model at a point in time. Your solution model contains the definition of your global data model, apps, services, and other solution-specific metadata generated from Appfarm Create.
Important
A snapshot does not contain any data from the database, such as objects you create and persist via data sources. It contains only the definition of your solution in Appfarm Create.
You can take a snapshot of model currently in Development at any time by clicking + next to Snapshots. Snapshots should be used as a regular part of your development process to protect against unintended changes and avoid data loss. It is often a good idea to take a snapshot before beginning on large scale or destructive changes.
To rollback your model to a previous snapshot, open the three-dot menu for the snapshot you wish to use and select Apply Snapshot to Develop.
Automatic snapshots is enabled in most Solutions. These will be taken roughly every 5-20 minutes when there is activity and changes made in the solution. A systematic clean-up is performed in order to spread out the snapshots so that there is more time between the stored snapshots the further back in time you go. If you do not have Automatic snapshots enabled, please contact support@appfarm.io.
Rollback to a snapshot means to restore the solution (Apps, Service, Global Data Model) in Develop back to a previous state. This may be used for disaster recovery if you delete or break a part of your application, or to perform a controlled rollback if you have been experimenting with a feature and would like to roll everything back. Note that only the solution (everything created in Appfarm Create) will be rolled back - not the application data.
You may rollback to both manual and automatic snapshots.
Rollback to a manual snapshot:
Rollback to an automatic snapshot:
Combining rollback to snapshot with the Copy to clipboard feature will also allow you to rollback a view etc. to a previous state:
Take a new manual snapshot (give it a proper name)
Rollback to a previous snapshot. Refresh Appfarm Create.
Locate the View, right-click and Copy to clipboard
Rollback to the manual snapshot created in 1). Refresh Appfarm Create.
Paste the View into your App.
As you deploy across environments, a deploy history is generated. This provides a record of who made the deploy, the solution model version deployed, and when the deploy occurred. If you run into issues on a new deploy, you can easily rollback to a previous deploy listed in the history. To do so, open the three-dot menu for the deploy you wish to rollback to and select Rollback to this version.
