Kernel R1 — Azure Deployment Pipeline

1. Deployment mechanism and release lineage

The implemented deployment pipeline is an operator-driven Python/SSH pipeline to an Azure VM. Its initial entry point is MR33_MIGRATION_WORK/deployment/azure/pipeline.py. Later Studio, Scheduler and UI corrections use release-specific pack/rehearse/deploy/verify scripts. No hosted Azure DevOps or GitHub Actions run is established by the retained deployment receipts. Azure hosting does not itself establish a hosted CI/CD pipeline.

The VM target recorded in the utility is kernal@20.244.50.199. The canonical user portal established on 11 October is https://portal.kernelhealth.tech; the compatible API origin remains https://api.kernelhealth.tech. The initial configuration's app.kernelhealth.tech belongs to an earlier deployment plan and must not overwrite the portal origin.

R1 is a handover baseline composed of multiple component releases. The 29 September base installation was followed by the portal edge release, MEDES technical delivery, 18 October Studio release, 19 October Scheduler/lifecycle release and later shared UI/IAM/Regulix corrections. Confirm the final active composition in the workbook's Release Baseline. Replaying an older package can remove later corrections even when that package passed its own tests.

Evidence: T01, T02, E05, E07, E01.

2. Deployment flow and stage gates

Freeze → Build/test → Clone rehearsal → Seal archive → Upload/stage → Backup/lock → Drain → Migrate → Activate runtime/configuration → Switch UI/edge → Verify → Issue UAT baseline.

D01 · Freeze and select release

D02 · Build and test candidate

D03 · Rehearse migrations and rollback

D04 · Package and seal

D05 · Transfer and stage

D06 · Backup and guard active baseline

D07 · Quiesce affected producers

D08 · Apply business then configuration changes

D09 · Install and activate runtime

D10 · Switch UI / gateway when in scope

D11 · Verify deployed installation

D12 · Issue baseline and hand over

3. Initial installation pipeline: exact stages

Run from the source workspace using the approved operator identity. The initial utility expects its private latest.json, a captured source backup inventory, SSH known-host file and protected release archive. These private assets are not included in the UAT ZIP. Establish the documented SSH control connection without storing passwords in commands or evidence.

pack captures current built runtime files/configuration and fresh database archives; it is not a clean Java/frontend build. Its private archive includes encrypted credential/provider material and document assets. Restrict that archive to operations; this UAT handover contains only sanitized evidence and references.

python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py pack
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py upload
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py install
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py provision
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py python_runtime
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py restore
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py configure
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py start
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py gateway
python3 MR33_MIGRATION_WORK/deployment/azure/pipeline.py verify

4. Incremental release recipes and exact artifacts

Studio: Vista, Pulse, source/dataset and output workers

build_plan.py produces the ordered migration plan; build_bundle.py seals frontend, workers, source evidence and offline renderer wheel/font assets. The acceptance chain is migration rehearsal, renderer parity, packaged role/theme browser checks and native dataset/Pulse journeys. readiness.py binds those proofs to the archive hash. deploy.py --rehearse-only performs release preflight; deploy.py activates only a matching READY bundle. Both require the private prepared operator environment; these are not unauthenticated self-service commands.

Target activate_remote.py validates the archive/manifest, takes backups, stops Vista/Tenant producers, drains existing output and stops renderer workers. It applies business then config migrations, installs pinned workers, publishes MEDIFLEX_VISTA and MEDIFLEX_TENANT Boot snapshots, restarts services, verifies endpoints, switches the UI pointer and writes DEPLOYMENT.json. It restores scoped databases/configuration, files, roles, units and pointer on failure. This 18 October release explicitly excluded Scheduler and Java runtime replacement.

Scheduler and generic lifecycle

build_plan.py orders 89 business and11 configuration migration entries. package.py requires the verified worker JAR, matching worker source hashes and built UI, then creates release.tar and MANIFEST.json. The target deploy_remote.py <staged archive> <expected SHA256> checks acceptance/rehearsal/profile/rollback proofs and current active hashes before proceeding. It is a release-specific target-side program, not a general deployment API.

The Scheduler runtime runs inside kernel-mediflex_core.service using the selected Module_Runner.jar. There is no separate enterprise-scheduler systemd service in this deployment recipe. The script creates a dedicated service identity, installs protected environment references before enabling Boot runtime configuration, waits for20 registered endpoints, restarts Core, requires a recent worker heartbeat, then switches the UI and checks profiles/lifecycle. The recorded release did not adopt existing jobs or attempt production delivery.

The release's package.py names a historical JAR in /tmp. Recreate/stage that exact verified artifact, or rebuild and issue a new manifest and acceptance record. Do not assume temporary files from an old run still exist. Application source, migrations and private artifacts are separate from this documentation ZIP.

Later UI / IAM / Regulix corrections

The scoped-query and Regulix-timeout deploy scripts update the currently active UI. Use their deployment receipts when freezing R1. A new candidate must include those corrections and preserve live runtime/configuration selections. Treat all module-specific scripts as dated recipes with preconditions, not an instruction to rerun every historical deployment in order.

Complete script/path/hash index · Recorded release and rollback locations.

5. Database and configuration promotion

The runtime database is mediflex_db; the deployment utility records configuration database OPS-REF-a061a8c0be47 (resolve in operator source baseline). Verify names in the target environment before use. OPS-REF-acaa995abe6a (resolve in operator source baseline) and endpoint_config feed Boot configuration; business IAM mappings, Axis metadata and module functions/tables are applied through the business migration plan.

Migration order is the plan's array order, not alphabetical filename order. The enclosed Migration Inventory preserves all36 Studio and100 Scheduler entries, database group, ordinal and recorded SHA256. It also compares the current local file hash; a SOURCE_CHANGED or SOURCE_NOT_PRESENT entry prevents treating today's source as the old tested artifact. The two release inventories overlap in dependencies and must not be summed as136 unique changes.

Business and configuration transactions do not form one cross-database atomic transaction. Stage executable undo and configuration predecessors before commit; on partial failure restore only the changes owned by that release. Boot publication/projection must be checked before service readiness is accepted. Preserve audit history and existing records; the Scheduler receipt preserves35 historical is_active null rows while checking256 tables.

Ordered migration inventory and source reconciliation; T20; T21.

6. Services, paths and ownership

Names/ports come from retained deployment source and receipts; confirm current installed units before operations. The initial25-service count is historical, not a current inventory.

7. Failure recovery and rollback decision

1. Stop further activation and preserve the failure receipt, phase, correlation IDs, active hashes and in-flight job/output identities. Identify whether only staging failed or a database/config/runtime/UI commit occurred.
2. Use the backup and undo files for the failed component release. A failed preflight leaves active application state alone; do not restore a whole database to undo a staging error.
3. For Scheduler failure after runtime selection, stop affected Core execution, restore configuration and wait for Boot rollback projection, apply release-owned business undo, restore private service selection/JAR, restart Core and verify readiness; restore UI pointer/web if it switched. Follow the script’s state flags and generated rollback files.
4. For Studio failure, use its captured files/units/roles, database undo and Boot predecessor snapshots. Reconcile accepted output before restarting producers; return queued work to its existing owner path.
5. For edge failure, restore portal Nginx/site/origin/gateway/UI backup and only the route created by that change. Retain the established API route. Validate nginx -t before reload and test host/callback/session boundaries.
6. Verify actual allowed and denied profile behavior after recovery. Record the recovered build, configuration, queue/worker state and outstanding defects; issue a revised baseline before resuming UAT.

Rollback of code is not rollback of delivered emails, fax submissions, created third-party records or other accepted external effects. Reconcile owner receipts and provider status before retrying. The base pipeline.py rollback does not restore databases or all later nested component releases. A database restore requires its own approved recovery plan, loss window and reconciliation.

Current HA/failover, automated blue/green or canary promotion, off-VM retention, measured RTO/RPO and a hosted CI approval pipeline are not established by these receipts. Record responsible operations owners and evidence before asserting those capabilities.

8. Deployment evidence required at UAT entry

1. Record release/change ID, operator, approver, timestamps, target URL/VM and maintenance window.
2. Attach source/lockfile references, UI/runtime/archive hashes and matching regression proof hashes.
3. Attach ordered migration inventory, baseline schema/config hashes, rehearsal and rollback results.
4. Record current services, gateway route/service/plugin/version projection, TLS validity and private secret reference ownership.
5. Record backup location/checksum, off-VM copy, tested restore and rollback decision owner.
6. Record post-deploy health, current asset hashes, fresh worker heartbeats, expected anonymous denials and authenticated maker/checker allow/deny checks.
7. Link residual defects and acceptance restrictions. Complete Environment, Release Baseline, Entry Gates and Sign Off; historical PASS evidence does not populate new UAT results.

Current release additions and acceptance

The following changes update the earlier handover baseline. Earlier results retain their original scope. The additional business UAT cases start Not run and require actual tester evidence.

Feature register · Additional UAT cases · New evidence index

MEDES entry gate: technical installation is complete; target activation is incomplete. Role grants, enabled APIs and document-review route must be verified before a live business demo. Provider-based delivery additionally requires approved provider setup and authorized destinations.

Verification boundary: the Axis screen-context release records 35 rollback-only database checks, 12 UI tests and 15 fixture-browser checks. The notification contract correction records 11 schema checks and 17 rollback-only database checks. These are not a complete authenticated production journey or a new client UAT sign-off.