Steps 1–2: Codebase and Dependencies
This is our first step in building out a personal blog following the model outlined by 12 Factor App. The first two steps are somewhat basic so we’re going to combine them together.
Codebase:
Some sort of version control system always maintains a 12Factor app. In a dev bootcamp, chances are, version control was one of the first, if not the very first thing learned. Version control allows changes to be tracked in the app and provides it with a real auditable history. Having one single codebase makes collaboration possible and makes the app able to be redeployed easily.
Believe it not there was a time before version control. I’ve only heard of these dark days from senior developers from their work years ago, but they really did exist. For them, it was the responsibility of one developer to maintain a single source of truth, that everyone would work from and ultimately submit changes to. Unsurprisingly this can lead trouble keeping everyone on a team in sync and working with the latest changes; is a major reason why version control is so important.
Today the most common version control system is Git, mostly bring hosted at GitHub although Gitlab and Gitea are also popular alternatives. Also worth noting are Bazaar, Mercurial, and Subversion all precursors to Git that you may encounter (Bazaar is still actively used by Canonical for Ubuntu, if you’re into open source you will likely come across it). For our purposes though, this website uses Git currently hosted on Gitlab.
While version control is likely to be one of the earliest things you learn in a dev bootcamp there’s a much lower chance you’ll learn about branching strategies. Simply put, branching strategies are patterns that specify how a repository manages its branches; it can define which branches are active, which are currently supported, and even which ones contain new work. The most popular branching strategy you’re likely to hear about is GitFlow, though there are many proponents of anti-GitFlow (I won’t elaborate on either here, there are MANY articles you could read if you decide to learn more). Branching strategies can also be straightforward instructions from the README of a repo. Either way, it is a good practice to keep your branches in some logical order and not work directly off of the master branch for everything.
Dependencies:
This part of your 12Factor App is rather straightforward; all dependencies must be explicitly declared and maintained. An app should never rely on the system to have all of the dependencies it needs to run. Ruby, of course, manages its dependencies through the Bundler gem, something explicitly discussed in the documentation of a 12Factor app. Eventually, when adding Javascript code to this blog, it will be managed via NPM and package.json. Clearly defining dependencies means that it will be easy to install, maintain, and update them.