Choosing Reuse Boundaries

Scenario: One opaque shared step performs checkout, tests, packaging, deployment, and notifications with dozens of flags.

Pipeline example

stage('Test') { steps { companyTest profile: 'node-service' } }
stage('Publish') { steps { companyPublish path: 'dist/*.tgz' } }

Reuse policy without hiding lifecycle

One companyDelivery step that checks out, tests, packages, scans, deploys, and notifies conceals agents, gates, and failure boundaries. Dozens of boolean flags create invalid modes and poor visualization. Prefer focused steps such as companyTest, publishArtifact, and requestDeployment while the Jenkinsfile retains explicit stages and application-specific ordering.

Keep deterministic build commands in repository scripts so developers can run them locally. Put approved credential patterns, standard evidence, and cross-repository Jenkins policy in the library. Put rollout reconciliation in the deployment platform. This separation assigns failures to owners and avoids coupling every build detail to Groovy.

Make abstractions diagnosable

A shared step validates early, logs safe inputs, preserves the underlying exception, and returns useful identifiers such as digest or analysis URL. Catching everything and returning false destroys stack and stage context. Offer a documented extension seam for unusual consumers without allowing routine policy bypass.

If every caller requests another flag, the boundary is too broad. If one security correction must reach fifty repositories consistently, centralization is valuable. Version and test the interface against representative Pipelines so reuse reduces operational variance rather than only source line count.

Goal: Practice the concrete behavior in jenkins-artifact-promotion. Learn sections have no Jenkins terminal; the Jenkins lab opens the real shared service in a new full-screen tab inside your private folder.