Things You Wish You Knew About Apps

…but were too afraid to ask.

My mentor pointed me to a resource, The Twelve-Factor App, for reading. I really like its brevity and straightforwardness. The reading encapsulates how apps should be developed and deployed, and just as importantly, provides a common language for describing various components of the process. Plus, this document is available in 11 different languages (what?!).

None of the following terms are from my own research and are from 12factor.net. I’ve outlined some definitions, but the authors wrote pretty extensively about concurrent processes that I think are valuable. Happy reading and learning!

  • Codebase: refers to a single repo or any set of repos who share a root commit. One codebase is an app. Multiple codebases are not an app; they’re actually a distributed system. Each component of that system is an app.
  • Deploy: a running instance of the app. This refers to the production site, any staging sites, and a local copy of the app running on a developer’s environment. Each of these qualify as a deploy since they have the same codebase, with perhaps varying versions. At various points of my not-very-length software development career, I’ve heard about deployment. The Twelve-Factor App summarizes the three stages pretty well:
The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches vendors dependencies and compiles binaries and assets.
The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment.
The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’s processes against a selected release.
  • Config: everything that varies between deploys and includes resource handles to the database and other backing services, credentials, and per-deploy values. Apps should not store config in code; rather, it is recommended to store them in environment variables.
  • Backing service: is any service that the app consumes as part of its normal operation. This includes the app’s database, messaging/queueing system, or cache. Many languages offer libraries to simplify access to the backing service and adapters to different types of service. Advice: do not use different backing services between deployment and production, as this may hamper compatibility and lead to bugs. All deploys (e.g. environment, staging, production) of the app should use the same type type and version of the backing services.
https://12factor.net/dev-prod-parity
  • Logs: stream of aggregated, time-ordered events collected from output streams of all running processes and backing services. They may be written to a file or watched in a terminal, and are helpful to find specific events, understand trends, and active alerting in the event that a threshold . Advice: each running process should write its event stream, unbuffered, to stdout. In staging and production, the streams should be routed to a final destination for viewing and long-term archiving (not visible by the app).
  • Admin processes: refer to administrative or maintenance task (e.g. running database migrations, console, or one-time scripts).
Like what you read? Give Malina Tran a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.