Terms

Terms

Every group of people working in similar areas develop their own distinct terms or words or phrases. Software folks are no different.

Here is a list of terms commonly used in these pages:

Build pipeline

This is the configuration and the build scripts used locally and in CI to construct and check your software, and build confidence to deploy to production. Since this process is linear (possibly with some parallel steps), it is pictured as a pipeline with code and artifacts flowing through steps and stages, and amenable to workflow diagrams.

CI

Always referring to Continuous Integration. This is a foundational practice and central to this book. Your CI build is your "system of record" for changes, and follows best practices for your project. It is a shared remote system that builds your software suitable for review and production deployment. Essentially, you want your shared CI build to be solid and consistent, and your local build (on your machine) to stay in sync with how CI builds your work.

Continuous improvement

Your goal is to support as many improvements (small or large) as often as possible in your projects, and leave things better than you found them. Not to be confused with "CI" (see above). This writing is about options for you to continually improve your build process and developer experience so that you can deploy awesome solutions to your users with confidence.

Cycle time

A key metric for you to evaluate your build checking how quickly local work flows through to deployed systems. Your build is often a bottleneck to quick releases, balancing quality against speed. This is closely related to the 4 key metrics from DevOps practices.

DevOps platform

These are typically commercial remote providers for a CI system for your project. Common examples include Azure DevOps, GitHub, and GitLab. This project uses GitHub for examples, however advice on principles for your build applies to any devops platform while features and details vary.

Shift security left

The concept of moving security to a first-class concern, and exposing security issues as early as sensible during development, and with as much automation as feasible. "Left" here means towards local development (if you picture your build as a pipeline moving from left to right). Examples include: checking project dependencies for known vulnerabilities, and calling out suspect code patterns or API usage. This project relies on static analysis and dependency checking to spot potential vulnerabilies locally, and again in CI, so that developers can address these before sharing work with users.

Software supply chain

There are many definitions such as What is software supply chain security? (RedHat). This writing understands Software Supply Chain to be evidence you show for confidence in software built locally and in CI. That evidence is artifacts and reporting constructed automatically as part of your build.

Static analysis

These are automation tools—part of your build process—that automatically check for quality and security concerns without manual effort. Automation is key here. The tools may run directly against project configuration, against source code, during compilation, or in steps after compilation. Examples include: code style, design constraints, known dependency vulnerabilities, suspect logic or missing corner case handling, use of outdated APIs etc.