- Environments
Sandbox
A sandbox is an isolated, on-demand environment for running, previewing or testing code without touching production. It has its own resources and data, so you can experiment, review a pull request or reproduce a bug freely - and throw the whole environment away when you are done.
- Supply chain security
SBOM (Software Bill of Materials)
An SBOM (software bill of materials) is a machine-readable inventory of every component that ships in a build: direct and transitive dependencies, exact versions, licenses, and cryptographic hashes. Generated at build time and attached to the artifact, it lets teams answer "is this vulnerable dependency in production?" in seconds instead of guessing across services.
- Security
Secrets management
Secrets management is the practice of storing, distributing, and rotating sensitive credentials - API keys, database passwords, tokens, certificates - so pipelines, applications, and infrastructure can use them at runtime without ever exposing the raw values in source code, build logs, or version control. Access is scoped per identity, audited, and revocable on demand.
- Release management
Semantic versioning
Semantic versioning (SemVer) is a version-numbering scheme that labels each release as MAJOR.MINOR.PATCH - bumping MAJOR for breaking changes, MINOR for backward-compatible features and PATCH for backward-compatible bug fixes. It gives consumers a predictable, machine-readable contract for what an upgrade will and will not break, so tooling and humans can reason about compatibility without reading changelogs.
- Reliability practices
Service Level Objective
A Service Level Objective (SLO) is a measurable reliability target for a service, such as 99.9% of requests succeed over a rolling 30 days. It defines what engineering and product agree the service must meet, and it anchors the error budget, alert thresholds, and release policies that follow from that promise.
- Deployment strategies
Shadow deployment
A shadow deployment runs a new version of a service in parallel with production and mirrors live traffic to it without affecting users. The new version processes real requests for observation, but its responses are discarded - so teams can validate performance, errors and behavior under genuine production load before any real rollout.
- Testing & quality
Shift-left testing
Shift-left testing moves quality checks toward the start of the software lifecycle - unit, integration, static analysis, security scans and accessibility checks run on every commit instead of waiting for a pre-release QA pass. Catching defects in seconds, not weeks, drops the cost of fixing them and shortens the feedback loop developers depend on.
- Testing
Smoke test
A smoke test is a small, fast set of checks run right after a build or deployment to confirm the system starts up and its critical paths work. It is not a full test suite - just a sanity check that the change did not break anything obvious before more expensive testing or real user traffic begins.