Strictly separate build and run stages
A codebase goes through several stages before transforming into an execution environment:
The build stage involves a process that converts the code repository into an executable bundle, known as the build. This stage, utilizing a root commit specified by the deployment process, retrieves vendor dependencies and compiles binaries and assets.
The release stage takes the output produced by the build stage and combines it with the deployment's configurations. The result of this combination creates a package ready for immediate execution within the execution environment.
The run stage (also referred to as "runtime") executes the app within the execution environment by launching a set of the app’s processes against a chosen release.
The Twelve-Factor app strictly emphasizes the separation between the build, release, and run stages. For instance, making changes to the code at runtime is impossible, as there's no mechanism to propagate those changes back to the build stage.
Every release should have its unique identification associated, such as a timestamp, and each release is an increment of the previous version. This implies that any modification must generate a new release.
The build process is initiated by developers when the code is pushed to an environment. In contrast, runtime execution can occur automatically, such as during a server reboot. Consequently, it's crucial to keep the run stage with as few moving parts as possible, as issues at this stage might prevent the app from running, especially during off-hours when support might not be readily available. The build stage can be more complex, as developers actively manage the deployment, keeping errors in the foreground.
This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!
Top comments (0)