Team standards with workspaces
Define naming, install, uninstall and detection standards once and reuse them across packages.
Packaging knowledge
Packaging in a team: standards and API
Standards, workspaces, CI/CD and audit: how several admins build the same packages without every package looking different.
Why personal standards fail
Two admins, two naming schemes, two detection patterns. Both packages work, but nobody can maintain them later without asking. Standards are not formalism; they are what keeps a package understandable after its author has moved on.
What a workspace fixes
A workspace bundles a team's rules: naming, install and uninstall patterns, detection defaults, templates. New packages start from the team convention, not from zero. Changes to the convention are visible and apply to everyone.
Approval and change
A standard anyone can change at any time is not a standard. That is why templates need approval and changes need a trail. If you need an exception, document it — not as a silent special case inside the package.
CI/CD without uploading installers
A pipeline can build packages without putting vendor files on a server. The job produces metadata and a result; sources stay local. That is the difference between automation and outsourcing.
What an audit answers
Not “who is to blame”, but “which version was on which device, when”. An audit answers that with events and metadata. It does not replace backups or tests, but it makes a change traceable when something goes wrong.
---
CI/CD for packaging without uploading installers
Metadata jobs, API keys and audit: connecting packaging to a pipeline without moving sources off-site.
Audit and traceability
Who changed which package when: which events are recorded and what they answer when something goes wrong.