So Far

- For Users

- For Developers

Up Ahead

- Production Readiness

- User Interface

- API Refinement

⏲️ Had I Had Time

2023-06-29

concepts

Had I had time, what would perfect automation look like?

So Far

For Users

From the book of "don't overwhelm me while I'm learning" (or, ever), the user experience has been refined to be understandable and safe.

Solid Foundations

Automation software built using the Peace framework allows users to:

See what would happen, before making it happen.
Press "go" multiple times, without adverse effects.

Changes Of Mind

There is some resilience to changes of mind and interruptions, and you are not punished for changing your mind:

_{ℹ️ Also, that state discovery step after interruption won't be necessary when peace#141 is implemented}

Profile Support

Peace is designed to support for working with multiple environments; though this part is still early days:

For Developers

Write Code, Not Strings

Type safety, compile time support, and code assist enables:

Easy discovery of what parameters are available – no more searching and pasting large chunks of YAML / JSON.
Errors at compile time – no longer waste time deploying to discover minor issues.
Writing code to pass values between items, not string templates.

Real code from env_deploy_flow.rs@0.0.11:

let iam_role_params_spec = IamRoleParams::<WebApp>::field_wise_spec()
    .with_name(iam_role_name)
    .with_path(path.clone())
    .with_managed_policy_arn_from_map(|iam_policy_state: &IamPolicyState| {
        if let IamPolicyState::Some {
            policy_id_arn_version: Generated::Value(policy_id_arn_version),
            ..
        } = iam_policy_state
        {
            Some(policy_id_arn_version.arn().to_string())
        } else {
            None
        }
    })
    .build();

No Minor Annoyances

The little things are taken care of:

Sorted values for clear and understandable diffs.
Sensible directory structure for separate and common values within a namespace.

❯ diff -u .peace/envman/demo_1/env_deploy/{states_goal.yaml,states_current.yaml}
 iam_role: !Some
   name: demo_1
   path: /
-  role_id_and_arn: !Tbd null
+  role_id_and_arn: !Value
+    id: AROASBLNZJUXOTGGPP7PX
+    arn: arn:aws:iam::140353555758:role/demo_1
   ..

repo/.peace/envman/demo_1/env_deploy
     ^      ^      ^      ^
     |      |      |      '--------- flow: cleanly separate information for different
     |      |      |                 workflows, e.g. "deploy" vs "load data"
     |      |      |
     |      |      '----- profile: logically separates environments
     |      |
     |      '----- tool name: allows multiple tools to be run in the same repo
     |
     '----- `.peace` data directory, like `.git`

Take care of the little things, that make the little difference, that make the big difference.

Up Ahead

There are three dimensions that I'd like to develop Peace further:

Production Readiness

The lifetime of an environment should be able to exist before, and live beyond, a version of the automation software that manages it.

For the Peace framework to be a sensible choice to build a production tool, the framework and items must be able to handle evolving data and logic. Namely, handling cases like:

Terminate these servers, recreate the VPC with resized CIDR blocks, then launch new servers in the new VPC.
This infrastructure was created manually, now it should be automatically managed, and migrated to use new naming conventions.

The Peace: Production Readiness GitHub project captures this work. See Flow Versioning for my technical thinking out loud notes.

User Interface

Two common methods to access automation are the command line, and the web browser.

Peace should provide support for:

Invoking commands to interact with the environment.
Presenting common data – usually States, but also ParamsSpecs, Params, errors, and progress.

Some of the CLI presentation logic currently lives in the envman example, and should be moved into peace, and the web presentation logic is currently "bundle leptos with the command line app and render the flow graph".

The Peace: UI GitHub project captures the start of this work. For the web UI part, see DEVELOPMENT.md#web-development.

There is some API that doesn't prevent developers from making mistakes or having mild annoyances through natural usage of the API.

The API should be refined to avoid setting up such situations, and implement additional functionality that makes it easier to work with information across profiles or across flows.

The Peace: API Refinement and Features GitHub project captures this work.

Had I had time, developing these would be excellent.

But I don't – I'm off to work!
🏃🏽‍♂️💨

< Prev