Join Frank P Moley III for an in-depth discussion in this video Factor 5: CI/CD, part of Twelve-Factor Applications.
- The fifth factor is the first one that deals more with how our code is managed in the ecosystem, rather than the actual code itself. What this factor aims to convey is that there should be distinct phases of the life cycle of a deployed application version. Now, CI/CD definitely makes this whole process easier, especially when leveraging pipelines, but as I just mentioned, this isn't a requirement.
We need to be clear that these phases are specifically addressing a non-production deployment. While this strategy can be applied to production deployments as well, often, production deployments simply involve quality gates, and then moving the bits from the non-prod to the prod environment. So with that being said, let's take a look at each of the stages as separate entities. The build stage begins with a developer or a development team.
He or she decides that the code is ready for deployment and either triggers a code review or they simply trigger the build themselves. Again, this is team dependent, and not that critical for the twelve factor methodology. What is important is that the code base is transformed into the build by a process specific to the language and framework. The build stage is the only stage that actually incorporates code changes.
And as such, new builds must be triggered to get new features or bug fixes into the environment. A release takes the artifact or artifacts from the build stage and combines it with its configuration to create a runnable component. The config is based on the current environment target and the artifact itself. But at this stage, no new code is introduced, only new configuration.
The code change impacts the build and the configuration change impacts the release. It is possible to modify the configuration without impacting the build. So a new release can occur without a new build. One important note is that each release should be tagged with a time stamp or version number. Once a release is created, it is considered unmutable. Version numbers, for instance, should only increment, and obviously, unless you're Marty McFly, time stamps only increment as well.
The final stage is the run stage. Basically, the run stage is nothing more than taking the release and executing the appropriate system processes to make your application run. Your running application should be completely tolerant of repeated restarts. In fact, constantly disposing of run time executions is a common security practice. And we all know that not every restart is controlled and crashes do occur in running code.
Now these three distinct phases of build, release, and run occur throughout the life of the application over and over again. I would highly recommend implementing CI/CD so you don't repeat yourself.
- What's cloud native?
- Managing dependencies
- Running processes
- Port binding
- Scaling with processes
- Environment uniformity
- Using your logs