Each slide covers one of the 12 factors, including what it is, why it's important and suggestions for how to implement it (with a focus on dot net applications). By Ed King, Pivotal. https://drive.google.com/file/d/13_lD7Ve68_VbLeew7iqlkEpBVuPy7wXO/view

1. The 12 Factors
> A methodology for building Software as a Service applications
> Originated from engineers working at Heroku
> A focus on stateless applications suitable for modern cloud platforms

2. The 12 Factors
> Codebase
> Dependencies
> Config
> Backing services
> Build, release, run
> Processes
> Port binding
> Concurrency
> Disposability
> Dev/prod parity
> Logs
> Admin processes

3. Codebase
What
> Each codebase must be stored in version control
> One-to-one relationship between application and codebase
> One-to-many relationship between codebase and deploys
Why
> To support collaboration between developers and teams
> To enable proper versioning
How
> Git, Subversion, Mercurial, etc.

4. Dependencies
What
> Explicitly declare and isolate application dependencies
> Use a declaration manifest that’s stored with the codebase
> Use a dependency isolation tool during application execution
Why
> Provides consistency between dev/prod environments
> Simplifies setup for developers new to the application
> Supports portability between cloud platforms
How
> Nuget

5. Config
What
> Ensure strict separation between code and configuration
> Store configuration in environment variables
Why
> Modify application behaviour without making code changes
> Simplifies deployment to multiple environments
> Reduce risk of leaking credentials and passwords
How
> Extract all application config to environment variables
> cf set-env

6. Backing Services
What
> Treat backing services (E.g. MySQL) as attached resources
> Make no distinction between local and third party services
> Attach resources via URLs stored in the app’s config
Why
> Provides loose coupling between service and deployment
> No code changes required to update backing services
> Allows operators to swap services out as they see fit
How
> cf marketplace, cf create/bind-service

7. Build, Release, Run
What
> Strictly separate the build, release and run stages
Why
> To prevent changes to code and/or configuration at runtime …
> … which in turn lowers the number of unexpected failures
How
> cf push

8. Processes
What
> Execute the app as one or more stateless processes
> Ensure all stateful data is stored in a backing service
Why
> Reduce deployment complexity
> Reduce operational complexity
> Allow for much simpler scaling
How
> Store any stateful data in backing services
> Do not use sticky sessions or the local filesystem!

9. Concurrency
What
> Scale out via the process model
> Treat processes as first class citizens
> Do not daemonize processes or attempt to write PID files
Why
> Allows for easy, horizontal scaling
How
> Split app into separate, runnable processes
> Scale independently

10. Disposability
What
> Maximise robustness via fast startup and graceful shutdown
> Treat app instances as cattle, not pets
> Be resilient to unexpected and sudden shutdowns (SIGKILL)
Why
> To facilite fast, elastic scaling
> To allow for rapid deployment of new code/config changes
> Provide robustness in production deployments
How
> Minimise work on startup, don’t depend on shutdown hooks

11. Dev/prod Parity
What
> Keep development, staging and production deploys as similar as possible
Why
> Lower risk of unexpected errors / downtime in production
> To support continues deployment
How
> Ensure the same backing services are used for all deployments
> Ensure a solid Continues Integration pipeline
> Deploy to production as often as possible

12. Logs
What
> Treat logs as event streams
> Log to stdout and stderr only
> Do not think about storage of logs at all
Why
> To make logging a platform concern, not a developer concern
> Improved flexibility for introspecting behaviour over time
How
> log to stdout/stderr only, cf logs

13. Admin Processes
What
> Run admin/management tasks as one-off processes
> Store code for admin tasks with the app’s codebase
> E.g. One-off debug tasks, REPL access to production
Why
> Safely support debugging/admin of production applications
How
> cf run-task