19 articles about Environments, in reading order.
Parsware Platform
In Parsware every environment has its own web address, so moving from Development to Test is opening Test's address, not choosing from a menu. Bookmark each one, and two browser tabs can never be confused about which environment they are in.
Parsware Platform
callService lets a server-side script post to another system, like a payment provider. The script never holds the address, only a service name. Each environment sets where that name points, so Test can use a sandbox and Production the real thing, and an environment that sets nothing reaches nothing. We took payments in a sample order app, and saw an answer, a refusal and a missing setting.
Parsware Platform
sendEmail sends a message through a mail service the environment names, just like callService. It never stops the script. It tells you whether the email went, and the script decides what to do about it. In the sample, a paid order records Sent or Not sent with the reason. Here is the call, what the mail service receives, and why an email step shouldn't refuse a save.
Parsware Platform
The whole path a change takes in Parsware: build it in Development, raise the solution's version, export one file, and import that same file into Test and then Production, where the new version replaces the old one. Plus the habits that keep the three environments in step.
Parsware Platform
Every Parsware environment keeps its records in its own database schema. A table name can mean different things in two environments, a record in Test can never show up in Production, and a query aimed at the wrong environment fails instead of returning somebody else's rows.
Parsware Platform
Creating a Parsware environment takes a name and a tier. The address is made from the name, the tier can't be changed later, and deleting the environment removes its schema, its solutions and everything that was built in it.
Parsware Platform
A solution only carries what's in it. When something it needs was built somewhere else, the import into Test is refused. Dependencies shows what's missing, Add existing puts it in, and Remove from solution takes things out without deleting them.
Parsware Platform
A managed solution doesn't overwrite the tables it touches. It adds a layer on top, so uninstalling it takes away exactly what it added: a table it brought, a column it put on Account, and nothing you built yourself.
Parsware Platform
Two publishers' solutions can sit side by side in one environment, and one can build on the other. Parsware checks the order both ways: an import that needs a table the environment doesn't have is refused, and so is an uninstall that would take away a table another solution still uses.
Parsware Platform
A solution can carry rows as well as tables. Each table's Seed data view decides which rows travel, and says what they are: configuration the solution needs, which every import brings, or demonstration data, which comes only when you ask for it, and never into Production.
Parsware Platform
One solution, a different setting in every environment. The declaration of an environment variable travels with the solution; the value stays where it was set. We followed two variables from Development through two upgrades of Test and into Production, and watched what each import changed and what it left alone.
Parsware Platform
A custom app or control is part of its solution, code and all. We exported Visitors from Development with its visitor board, its badge field and its web resources, imported it into Test, and watched an altered copy of the same file get refused.
Parsware Platform
Packing and uploading a control for every change is slow. In a development environment, register its running dev server instead: save a change, refresh the form, and it's there. We fixed the badge field's dash this way, then packed 1.1.0 when it was right.
Parsware Platform
A team is a group of people that records can belong to, and it can hold a role. We put Alex and Jordan in Field Sales North, gave the team the Field Sales role, and watched Jordan's open session gain New on its next refresh, with no sign-out.
Parsware Platform
The unit policies need an organisation to measure against. We built one in the Organisation app (Head Office with a North and a South region), put three people in it, and gave Jordan read access on My unit and below. From Head Office, Jordan sees the accounts both regions create, and nothing owned outside the chart.
Parsware Platform
Each customer is a tenant: its own people, environments and data. The people who run a deployment can switch a tenant's sign-in off and on again from Tenants. We deactivated Tailspin Toys while its administrator was signed in, watched the sign-in refused, and switched it back on to find everything where it was.
Parsware Platform
When a trial runs out, nothing is deleted and nobody is locked out. Everyone can still sign in, read and export; only changes stop, and the data is kept for 60 days. We let Tailspin Toys' trial end while its administrator was working, watched a save refused and the units still readable, then subscribed and carried on where it stopped.
Parsware Platform
Parsware is for organisations whose work runs on forms, approvals and spreadsheets passed around by email, and who want those turned into real applications without running the servers themselves. This is what it's for, who it's for, and what a tenant actually gets, shown on the capital planning sample.
For Power Apps
A published Parsware design is an ordinary component of your own solution, so it moves from development to production the way everything else in Power Apps does. Export the solution as managed and import it. Production needs the Parsware runtime and nothing else. Here is a report taken from one environment to another, every step pictured.
