Skip to content

Dev → Test → Live Deployment

The Golden Rule

Always follow: Dev → Test → Live. Never develop in Test or Live. Changes flow strictly in one direction.

Step-by-Step Deployment

  1. Open the 1stTouch/Versaa/Aareon Mobile desktop app.
  2. Click the settings icon → view the current environment.
  3. Click the environment name → Edit → select the target environment.
  4. Click Validate → enter credentials → Validate again.
  5. If validation fails: check Active Directory permissions. Raise a helpdesk ticket if needed.
  6. Make changes in PrtyDev.
  7. Export a package from Dev.
  8. Import the package into PrtyTest.
  9. Business testing and sign-off in Test.
  10. Export from Test, import into PrtyLive.

Checking Version Comments Before Deployment

Always verify version comments match across environments before importing. Silently overwriting can lose another developer's work.

  1. In Form Designer, open the form in the source environment (e.g., Dev). Note version number and comment.
  2. Open the same form in the target environment (e.g., Test). Check its current version comment.
  3. Confirm consistency — the target's latest version comment should match an earlier version in the source.

If comments don't match: - Option A: Update the target to match first, then re-test before importing. - Option B: Make a targeted fix directly in the target, add comment including "emergency fix" so it's traceable. - Never silently overwrite.

Example: Dev is on v1206, Test is on v1124. Check that v1124 in Dev has a matching comment to v1124 in Test before importing.

Form Creation Control Document

Before starting any development, record every form you intend to change:

Form name Version before Version after Description of change

When migrating, the control document tells you exactly what to export and import — nothing gets missed.

Manual Changes in Live

If a manual change is made directly in Live, immediately replicate it to Test and Dev to maintain consistency.

Quick Tips

  • Always back up before making changes (export the current version as a package).
  • Regularly check Active Directory permissions to avoid deployment delays.
  • Be cautious of concurrent changes — compare version comments before every deployment.
  • Use the Form Creation Control Document on every development task.
  • Always test yourself in Test before handing to users. You'll catch "sillies" early — there will always be minor issues after migration. User testers should not encounter obvious bugs.

Closing a Freshdesk Ticket

  1. Deploy the fix/feature to PrtyLive (Dev → Test → Live process complete).
  2. In Freshdesk, click Resolve ticket.
  3. Send a message confirming: "We've migrated the changes from dev to test, from test to live. This is now live."
  4. The act of deploying to Live is what enables you to close the ticket — it is not closed when users pass testing in Test; it is closed when it is live and working.

Packaging Strategy for Deployments with Multiple Changes

When migrating a set of related changes, package them carefully:

  • Package related items together (e.g., CRR form + its workflows + its template = one package).
  • Keep risky/unfinished items separate — if one part of a change isn't ready, don't include it in the package. The rest can go live safely.
  • Incomplete workflow steps are safe to deploy if they are no-ops — if a workflow step exists but doesn't do anything yet (e.g., a condition branch that currently completes without effect), it will not break anything in Live. You can add the logic later.

Example (session 10): The Repair Works Order completion workflow had a new step added for CRR processing that wasn't working yet. Peter confirmed it was safe to migrate everything else because that step "goes — there's a step that I do nothing with, move on. So it doesn't actually break anything."