| 13 | Three parts to a container system workflow: |
| 14 | * source code that will execute in the container |
| 15 | * the build environment that prepares source code to run |
| 16 | * built containers ready to be copied and executed |
| 17 | |
| 18 | Source code systems are converging on the git workflow, where each commit is a signed difference to a source code base, organized by branches, with notable commits marked with tags. The git workflow, pioneered by the Linux kernel developers and Linus Torvalds, has gained immense industry adoption when combined with a web-GUI like github, or similar projects like gitea. A feature of the git workflow is that there is an audit trail, for practical purposes resistant to forgery or modification after commits. |
| 19 | |
| 20 | Secondly, the build system that creates the container code is more and more a formal system itself. It is not entirely solved, but practical methods of identifying and obtaining standard FOSS build environments is the industry direction. Specific build environments include: Java, C++/C, node.js, php, Rust and Golang. |
| 21 | |
| 22 | Third, a completed container may be signed and available in a repository. Early versions of Docker had only one, hard-wired source of containers, but more recently container registries have become part of the Docker project. Due to converging industry efforts, Docker and K8s enjoy a special relationship, now and going forward in the forseeable future. |