The Twelve Factor App Part 1: Codebase, Dependencies, Config Backing Services

The 12-factor app represents a methodology of creating Software-as-a-service (SAAS) app. Main characters of created 12-factor app must contain declarative formats for setup automation, portability option, option of modern implementation on Cloud platforms, System Administration, free space for continuous deployment, and scale up possibilities.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). (Source)

In this Chapter we will cover the first four factors of complete methodology.

Factor 1: Codebase

A 12-factor app is always tracked in a version control system, stated as: “One codebase tracked in revision control, many deploys.” (Source)

In this factor, multiple codebases and multiple apps with shared the same code, breaks the twelve-factor methodology, and each of them have a solution to avoid this scenario. There is only one codebase per app, but there will be many deploys of the app. A deploy is a running instance of the app. This is typically a production site, and one or more staging sites. (Source)

Factor 2: Dependencies

A twelve-factor app never relies on implicit existence of system-wide packages. It declares all dependencies, completely and exactly, via a dependency declaration manifest. Furthermore, it uses a dependency isolation tool during execution in order to ensure that no implicit dependencies “leak in” from the surrounding system. The full and explicit dependency specification is applied uniformly to both production as well as  development. (Source)

Factor 3: Configuration

The safest approach to save and maintain an application’s configuration is to use env vars, which implies externalizing and storing the config in the environment. Non-changeable components do not belong in the configuration since it comprises of components that are variable throughout different deploys. Internal information that is part of the app must not be included in the  configuration. To clarify, if a value is consistent across all deploys, it isn’t configuration. According to twelve-factor rules, configuration should be kept distinct from code, because code doesn’t vary across different deploys, but configuration often does. With this separation, it is easier to alter environment variables as no code is being affected.

It’s extremely important to be cautious while keeping security credentials - they should never be kept in the codebase. Bundled assets remain part of the codebase even if security credentials are stored in some properties files or retrieved from the source code. Since environment variables are maintained individually for each deploy, the application concept that contains them scales efficiently. (Source)

Factor 4: Backing services

A backing service is any service the app consumes over the network as part of its normal operation. Example includes datastores, messaging or queueing systems, SMTP services for outbound emails and caching systems. Both local as well as third-party services are considered equivalent as they are associated to the app and accessed via URL or other configuration credentials. Each backing service is considered as a resource which may be integrated to and excluded from deploys at a certain moment. Resources can be attached  and detached from deploys at any time.

For example, if the app’s database is misbehaving due to a hardware issue, the app’s administrator might spin up a new database server restored from a recent backup. The current production database could be detached, and the new database attached – all without any code changes.

Do you work in IT or are you interested in IT-related topics? Then feel free to visit our blog for more topics and follow us on LinkedIn.