Publishing Apps
Publishing an app in DynaMaker is straightforward. In this tutorial you learn the basics.
Use any app you have built that already has a working User Interface (UI), no matter how polished it is. This tutorial does not require coding, only a few clicks.
You complete three steps:
1. Prepare App
To publish an app you need:
- A. Working App
- B. Subscription
A. Working App
First you need the UI working. It can be a standalone DynaMaker app or integrated with other software. In this example the staircase app from the Assemblies tutorial is used:
B. Subscription
You need at least one DynaMaker subscription:
- Go to your team dashboard (where all apps are listed).
- In settings (cog wheel), open Subscription.
- Make sure you have at least one subscription (click Upgrade Subscription Plan to see pricing details).
To illustrate, in the example above the team:
- Registers and starts with no subscription (default plan Lite) and no available application licenses to publish apps.
- Purchases one DynaMaker Standard subscription, changing plan and unlocking one unused application license.
- Publishes one app (shown later) which uses the application license unlocked by the subscription.
Publishing an app allows any user (with access) to open the autogenerated URL. For the staircase app the URL is:
Essentially: 1 published app = 1 DynaMaker subscription. However you can have as many unpublished apps as you want.
2. Publish App
Now publish your first DynaMaker app. As a best practice, first publish to Test, then to Production:
A. Test Site
Publish to the Test site:
- In your app dashboard, click Publish to Web.
- In the Publish to Web dialog, click Skip tests.
- In the next popup, click Assign Application License To This Application. Because this team has one DynaMaker subscription, you see "1 available application license".
- Click Publish to Test.
- A new browser tab opens with the published app. Note the word "test" in the URL before the app ID SqyYLALsv4Q:
- The dashboard updates and the Test site button is now enabled. If you hover over the timestamps you see the exact date when the last publishment took place:
B. Production Site
After testing and fixing any bugs, publish to Production so customers can start configuring staircases:
- Click Publish to Web.
- Click Skip tests.
- You do not need to assign an application license again (this is only needed once).
- Enter the name of the app in the input field: Staircases.
- Click Publish to Production.
- A new browser tab opens with the published app. The word "test" is no longer in the URL:
You now have a Test and Production environment for the app. Whenever you want to update the published app, publish to the corresponding site to override the version there.
3. Understand Publishment
Your application can exist in three environments:
- Editors: what you as a developer work with continuously, and what the user never sees.
- Test site: published app meant to show experimental changes, typically for user testing.
- Production site: published (error-free) app meant to be used by the user, it must be polished.
The typical workflow of publishing an app (see picture above) is:
- Building App: Developer builds the app based on requirements (editors v1).
- Implementation: Developer adds the feature (editors v1 → v2).
- Internal Testing: publish to the Test site (test v1) and share the URL with e.g. Sales for feedback.
- Bug Fixing & Improvements: if Sales reports issues, developer fixes them, improves code (editors v2 → v3 → v4), and republishes to Test site (test v2) for re-review.
- Approval & Release: once approved, publish to Production site (prod v1) and give Sales the customer-ready link.
- Next Cycle: Sales gathers new feature requests while customers use the current version; developer works on them in editors (v4 → v5), then repeats the cycle.
This is how the published app looks when embedded:
Have you found bugs and have no clue where they are coming from? In the next tutorial (Debugging) you learn how to find, isolate, and fix errors yourself by debugging your code.