Release authoring

1. Create a release in Development.
2. Select the definitions to include.
3. Review the environment comparison.
4. Apply it to QA. QA is pinned to the new release version.

Production is never a Studio target; promote to Production through your own release process.

How releases work

Every TechAppForce app has environments, and each environment keeps its own version of the app's configuration. When you publish an item in Studio, it lands in the environment you are signed in to, normally Development. Other environments do not change until a release carries the change to them.

A release is a named, numbered record of which changes should move. That makes a promotion something you can review: you see the list of changes before anything is applied, and the release stays on record afterwards. For the concepts behind environments, see Environments and releases.

Compare environments

Run TAF: Compare Environments to see what promoting would change: which items were added, changed or removed between two environments. The comparison is read-only and opens as a document in your working folder, so you can read it, search it and share it before deciding what goes into a release.

Create and deploy a release

TAF: Releases lists the app's releases and what each one contained. To ship changes:

• Create a release. The platform assigns its release number.
• Choose the changes it should include. You pick from what differs between Development and QA, so a release can carry one feature without dragging along unrelated work in progress.
• Deploy it. Studio applies the release from Development to QA and records it in the release list.

What a release carries

A release can include two kinds of change:

• Configuration. The app's definitions: objects and fields, queries, screens, lifecycles, workflows and the other items you design in Studio.
• Reference data. Rows in your app's tables that the app needs to work, such as choice lists or settings. The platform applies them in an order that respects the relationships between tables.

Migration scripts can travel with a release too, so a change that needs a data fix is promoted together with that fix.

Where Production fits

Studio deliberately stops at QA. Production releases are handled outside Studio by the team that runs your production environment, so the step that affects your customers stays a separate, deliberate decision. The same release model applies all the way through: what you tested in QA is what gets promoted.