Endevor- Packages

A package is Endevor's unit of release: a container that holds a tested set of element actions (moves, generates, deletes) and carries them through approvals into production as one atomic unit. Moving twenty elements with twenty separate MOVEs is chaos; moving one package is a controlled release.

Packages are how real shops ship changes. Developers build packages, the package is cast (frozen and validated), approvers approve or deny it, and then it is executed - Endevor performs every action inside it, in order, against production.

Standard vs expedited packages

• Standard package - the normal release vehicle. It goes through the full approval path: cast, approver review, approval, execution window.
• Expedited package - for emergencies (production fixes). It follows a shorter approval path defined by your site, but it is still recorded, still audited, still backed-out-able.
• Both types move the same way and both appear in the audit trail. "Expedited" never means "uncontrolled" - it means "pre-authorized fast path".
• Your site defines which package types exist and who may create each. Most developers only ever create standard packages.

Package lifecycle states

• IN-EDIT - being built. You can add, change, or remove actions freely. Nothing is frozen.
• IN-APPROVAL - cast and waiting for approvers. Actions are locked; approvers review the contents.
• APPROVED - every required approver said yes. Ready to execute in its execution window.
• IN-EXECUTION - Endevor is running the actions now.
• EXECUTED - finished successfully. The release is live.
• DENIED - an approver said no, with a reason. Back to IN-EDIT for fixes.
• EXECUTION FAILED - something went wrong mid-run. The package stays visible with error details until resolved or backed out.

Building a package in the foreground

1. Create the package: give it an ID (your site's naming standard, e.g. PAY000123), a description, and the from/to environments.
2. Add SCL statements - the actions the package will perform, e.g. MOVE PAYROLL1 from stage T to stage P.
3. Optionally add notes for approvers: what changed, test evidence, backout plan.
4. CAST the package. Endevor freezes it, validates every action (elements exist, authorizations hold), and routes it to approvers.
5. Approvers review and approve (or deny with reasons).
6. EXECUTE the package in its window. Endevor runs each action and reports results.
7. Verify in production; keep the backout package/plan ready per site procedure.

Package SCL example - batch

Packages can also be driven with SCL in batch. This example creates a package, casts it, approves it, and executes it:

In practice the SCL inside the package - the actual element actions - is usually built with foreground panels (option "Package" then "SCL"), which validate each statement as you add it. The CREATE/CAST/APPROVE/EXECUTE verbs above are the package-level controls.

Approvals and approver groups

• An approver group is a list of people (or roles) whose yes-vote a package needs, e.g. the payroll team lead plus the release manager.
• Some groups need a quorum - say 2 of 3 members - others need every named approver.
• Approvers see the full action list, the SCL, and your notes before deciding. DENY requires a reason, which you see when it returns to IN-EDIT.
• Approval authority is separate from action authority: you may be allowed to MOVE to TEST but not approve a production package.
• Emergency (expedited) packages route to a smaller on-call approver list - defined in advance, not invented during the crisis.

Cast, backout, and shipment

• CAST freezes the package: no more edits, full validation runs, approvers are notified. A failed cast lists exactly which action is invalid - fix it in IN-EDIT and cast again.
• Backout reverses an executed package: Endevor runs the inverse actions (move the old levels back). Always prepare the backout plan before executing.
• Shipment sends package outputs to another location or system (tape, dataset, remote site) as part of execution - common in multi-site shops.
• Executed packages are never deleted casually - they are the audit evidence that a release happened, who approved it, and when.