Twelve Factor App - Build, Release and Run

Twelve Factor App - Build, Release and Run

The concept of the Twelve Factor app was developed by engineers at Heroku to describe the core principles and qualities that they believe are key to the adoption of the Software as a Service (SaaS) methodology.

First published in 2011 the Heroku platform is unashamedly opinionated in the enforcement of these principles, the relevance of them to effective software development has only intensified as the adoption of cloud computing has increased the number of us deploying and managing server side software.

The fourth principle relates to the strict separation of the build, release and run phases of application development:

"The delivery pipeline should strictly consist of build, release, run."

Development to Deployment

A codebase is transformed from source code to a working application in three stages.

The Build stage converts source code into an executable binary. The resultant binary is a combination of source code produced by the development team, 3rd party dependencies and the underlying framework being used to produce the application.

The Release stage takes the binary and combines this with configuration suitable for the environment that it will be deployed into.

Finally the Run stage starts the application in the environment, bringing it to life and making the functionality it provides available to the rest of the estate.

The exact nature of all of these stages will vary greatly depending on the technologies being used during development but the essence of the three distinct stages remains. Build your code, combine it with configuration and deploy, then finally run your code in the environment.

An app following the twelve factor principles strives to maintain this strict separation.

Isolation of Change

The first important aspect of maintaining this separation is to isolate where functional changes can be made. As an example functional changes to the application should not be made as part of the run phase. Any such changes cannot be pushed upstream to the build phase and therefore create inconsistency during development and testing.

It maybe that configuration changes made during the release phase can also affect functionality but these changes can be easily applied during development in a consistent and controlled manner.

By properly isolating change we increase the repeatability of the entire process to produce consistent results, not only in a production environment but for local and shared development environments as well.

Always Releasing

Release and run and phases should be as simple and quick as possible. Not only is this a desirable quality for any piece of engineering but in a modern cloud based architecture deployment is a frequently occurring operation.

As an environment scales out with more copies of your application being required a reliable and fast deployment mechanism is essential in being able to respond to demand.

A slick and fast deployment process also reduces the amount of time it takes from developer commit to running in production. The compound effect of these marginal gains enables consistent gains and improvements in your applications performance and effectiveness.

Finally an effective release process also enables strong rollback strategies when a change into production needs to be reversed. The more complicated the release process the more any rollback is a leap into the unknown and the less likely that the environment can be returned to a working state quickly.

The need to keep these three phases separate may on the face of it seem obvious but inefficiencies and sub-optimal changes can easily cause the line between them to be blurred over time. Recognising the impact this has and being on the look out for anything that goes against this goal is key to maintaining a healthy development environment. As with most aspects of software engineering this is more of a goal than an absolute but being driven by the correct principles will never normally steer you wrong.

要查看或添加评论,请登录

Ben Walpole的更多文章

  • The Virtual World

    The Virtual World

    I don't have any statistics to back up this claim but given the prevalence of cloud native approaches I am willing to…

  • Distributing Problems

    Distributing Problems

    Patterns and practices in software engineering can be very cyclical, the names and terminology applied can change but…

  • Solid State World

    Solid State World

    It's often said that technology moves quickly, I'm actually of the opinion that its our learning of how to utilise…

  • Network of Networks

    Network of Networks

    When we're searching for analogies to describe the operation of the internet we often fall back on that of posting a…

  • Underpinning Kubernetes

    Underpinning Kubernetes

    Kubernetes is the de facto choice for deploying containerized applications at scale. Because of that we are all now…

  • Compiling Knowledge

    Compiling Knowledge

    Any software engineer who works with a compiled language will know the almost religious concept of the build. Whether…

  • Terraforming Your World

    Terraforming Your World

    Software Engineers are very good at managing source code. We have developed effective strategies and tools to allow us…

  • Being at the Helm

    Being at the Helm

    The majority of containerized applications that are being deployed at any reasonable scale will likely be using some…

  • Avoiding Toiling

    Avoiding Toiling

    Site Reliability Engineering (SRE) is the practice of applying software engineering principles to the management of…

    1 条评论
  • The Language of Love

    The Language of Love

    Software engineers are often polyglots who will learn or be exposed to multiple programming languages over the course…

社区洞察

其他会员也浏览了