Terms

Every group of people working in similar areas develop their own distinct terms or words or phrases. Software folks are no different. So what is "clear language" for those in the industry, but carry connotations and expectations, might not make immediate sense to those new or from different backgrounds; and specific language varies even within the software community.

So in these pages, we'll try to stick with consistent language:

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). 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.