- The implementation should be guided by the realities of what you’re testing. Do you have physical machines like FPGAs you’re testing? If so, you probably can’t use certain types of virtualization technologies effectively
- The environment should be deterministic and reproducible
- The configuration for the CI/CD implementation should be declaratively specified but ultimately it’s not a concern of what you’re testing
- Configuration should be idempotent
- Deployed branches are always green
- Every individual commit in a deployed branch represents a working application
- Development Environments
Environment and Context
- Properties of CI/CD/CC
-
Project Metrics
For performers of a project, it can be helpful to think of the project as its own entity that has a concept of health. After all a project has its own Environment and Context, and the desired environment should be intentionally cultivated. Healthy environments have teams with high Psychological Safety, which empowers them to have and enrich an already Effective Organizational Culture.
-
Environment Parity
Facilitates consistent Environment and Context and Local Reasoning
- Environment
-
Don’t Special Case Administrative Tasks
Facilitates using a consistent Environment and Context when Developing Good Explanations
-
Deploy is not Release
Facilitates consistent Environment and Context reasoning
- Context
- Configuration
-
Build Systems Suck
Each result can be defined as a function that takes Environment and Context as an input and outputs a reproducible artifact. The generalization of tihs approach results in constructing a forest of roots that result in a DAG. However, sometimes the Acyclic bit is too strong of a constraint, so I think we can relax that to a bounded level of cyclic behavior, keeping in mind the principle of Automation With a Human Touch - Jidoka. That all said, something that I think is even more important than being able to specify the fully generalized DAG is being able to specify efficiently and ergonomically the caching behavior and artifacts that are dependencies of steps. You would think this would be implied by the DAG. DAGs are, after all, fully composable and the representation of a build system in a DAG would contain, for each node, the full closure of everything required to reproducibly create the artifact. But nooo, this has to pointed out. So here’s my ranty rant pointing out that if your CI/build system doesn’t have a way to performantly deal with artifacts, dependencies, and environmental closures, its automatically got a lot of flaws and limitations that didn’t need to be there.. (looking at you in particular, github; you had a lot of time to learn from the mistakes of others)
-
3 Steps of Software: Encoding Knowledge
Don’t forget the Environment and Context. Think about the person next to you. Not a lot, but keep them in mind so that you write the thing that’s the Simplest, But No Simpler.
-
12 Factors
This is done by having a consistent Environment and Context.