The Environment Is Automated in the Code

A key idea (maybe the key idea) of DevOps is that the environment in which your code will run should be modeled as code, and not be some separate thing that is a black box. (And, as we get a bit further down the stack, should be versioned with the code as well.) It seems pretty basic, but the idea is that you should have a “recipe” that allows you to recreate the environment at any moment. Some of the key parts of managing the environment include:

• General configuration. General configuration includes setting up the basic requirements for the app to even run, things like ensuring that whatever directory it will live in actually exists, creating any required users, setting up security groups, specifying where log files should be stored, exposing (or blocking) the proper ports, setting any required permissions, installing any license or cert files, and updating packages. In short, anything and everything that an app needs at the basic operating system level.
• Installation of the application stack. If you’re writing a Rails app, for example, you’ll need to have the required versions of Ruby, Rails, bundler, and other stack-specific dependencies. The same goes for any other stack.
• Installation and configuration of the required backing services. The 12 Factor App describes backing services as “any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such as Memcached).” Backing services can also include third-party services, like Amazon AWS (SQS, dynamodb, etc.), GitHub, Twitter, and Parse. Ideally, the “code for a twelve-factor app makes no distinction between local and third party services.”