From the editor to the device
A solution's definition becomes a running system on real targets as one continuous program: defined, emulated, deployed, provisioned. Between your editor and a customer's machine there is a twin that holds no reference to reality.
The road, in five steps
- Define. The solution and its targets are declared as artefacts before any feature code. Feature code is written in a deployment scope that the target can refuse. built · see from dev to deploy
- Emulate. The whole solution runs on a twin, a copy of the system that holds no reference to the real one. built · see emulating the whole solution
- Plan and provision. The plan says what each target needs and in what order. built · see planning and provisioning
- Deploy. Provision, then store, then launch, then verify, with rollback, by an actor that may commit. A build can be deployed to emulation freely and to production only through the plan. built · see deploying to target sites
- Hold the secrets. Credentials are held in a store that redacts itself, and the governance crossing is the only road to production. built · see secrets and credentials
The Softanza way A solution is rehearsed before it is committed, and a fake dependency is allowed on the twin and refused in production. What you see work in emulation is the same program that is deployed, and the court that judges it does not change between the two.
in construction The deployment guard passes 45 assertions of 45, read from the library's files. Live hosts are gated by infrastructure: the plane has been exercised against emulated targets, and a real customer host is where the remaining work is. The articles above run in this site's runner where they can, and their pages say which blocks kept their promise.