Deployment plans
In AEL, the Agent Engineering Language, a deployment will be two explicit steps: ael deploy plan (command names may change before launch) will work out what a deployment changes and show it for review, and ael deploy apply will carry out exactly the plan you reviewed.
Status
Planned for AEL Beta 0.0.1. AEL is not available yet.
Usage
ael deploy plan
ael deploy apply --plan <plan>
| Command or option | Meaning |
|---|---|
ael deploy plan | Build the plan and show it, changing nothing. |
ael deploy apply | Apply one reviewed plan. |
--plan <plan> | The plan to apply, as ael deploy plan identified it. |
--json | The plan, or the progress of applying it, in machine-readable form. |
What a plan shows
A plan will be fixed once it is made. It will name:
- the programs and firmware images to deploy, and the devices or machines they go to;
- the prompts, model bindings, tools and permissions of each agent, by their exact versions;
- where each part runs, including what runs on a device and what runs on a gateway that serves it;
- how each device behaves if it loses its connection;
- whether each change is compatible with what is deployed now;
- the evaluation results of the prompts it deploys.
A change that widens a tool's permissions will need a new, authorized plan: a prompt update alone will never be able to widen them.
What applying does
- Checks the plan is still true. If a device, a machine or the deployed version changed since the plan was made,
applywill refuse the plan rather than deploy something you did not review. - Stages. It will put every new part in place without switching to it.
- Checks readiness. It will confirm each staged part is ready.
- Activates. It will switch to the new version in a set order, so a device never starts using a new prompt or tool while the part that serves it still runs an older, incompatible one.
Runs already under way will stay pinned to the version they were admitted with, to the end. New runs will use the new version.
Rollback and recovery
- Rolling back will be one step, to the previous compatible version: the last known-good programs, firmware and prompts will be kept for it.
- Each step of an apply will be recorded. If the connection is lost or one part fails,
applywill find out what is actually deployed before it retries, and report a state it cannot determine as unknown, never as done. - A compatible prompt-only change will not need a board to be flashed again. A change of types or permissions may need new firmware and a coordinated update.
Never automatic
Building, testing and evaluating will never deploy anything, and a deployment will never flash a board unless its plan says so and you apply it.
Not settled yet
The format of the deployment description that ael deploy plan reads, how you choose which deployment to plan, and how you roll back from the command line will be described when the deployment format is final. Deployment and rollback describes staged deployments in full.
Related
- Running evaluations and Comparing prompts: the steps before a plan.
- Evaluations and prompt releases: promotion and rollback.
- Flashing a board: writing firmware by hand.
- Deployment and rollback: plans, staging and rollback across programs, gateways and boards.