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 first principle relates to the management of the applications source code:
"There should be exactly one codebase for a deployed service with the codebase being used for many deployments"
Source Code Management
Very few if any teams would now debate the need for source control. Even if you are coding as a lone range the ability to properly organise and manage updates to source code is fundamental to engineering software as opposed to simply coding for fun.
A twelve factor app is contained in a single repository and deployed multiple times.
Whilst there is now very little, if any, debate on the need for source control there are still practices that should be followed to maximise the benefits. These include but aren't limited to:
- An effective branching strategy to properly separate day to day development from release activity.
- Using source control features such as git's commit squashing to ensure a clean and readable history of key code base changes.
- The ability to revert and re-deploy changes when their introduction cause unintended and undesirable consequences.
Self Contained Repository
The repository for your application should contain everything that is required to build and run your application. If your application is actually multiple applications masquerading as a single entity then each distinct application should itself be written as a twelve factor app.
The first of the twelve factor principles actually states that applications sharing code, at a source code level, is undesirable and instead should be based on libraries using a dependency management solution. This is in contrast to the monolithic repository approach that has gained popularity over recent years.
My personal feeling is that the essence of the principle can still be achieved whilst also benefiting from a monolithic repository. It is still the case that cloning a single repo gives you everything you need to build, run and deploy an application. Being able to view the source of all your internally written dependencies provides a great deal of insight into how your code base works, and still allows a single code base to be deployed multiple times.
Many Deployments
There are many reasons why you may need to deploy your application multiple times. It could be that the application provides functionality needed by multiple aspects of your system, or in a cloud computing world your application may be deployed multiple times as your application scales up or out.
For this process to be efficient all deployments should be using the same code base and deployment mechanism. That is to say that the code base shouldn't require modification based on the environment or context it is being deployed into.
If this isn't the case it makes the predicability of the impact of changes harder to gauge and will lead to instability if the differences between deployments is not properly understood by all members of the team.
The first of the twelve factor principles may now seem so fundamental to good software development as to be an obvious mandate. It's fundamental nature means it provides the required under-pinning to build a solid foundation for the principles to come. It is also never a bad thing to be reminded of fundamentals that may seem like common sense but can easily be forgotten.
Source code makes up the building blocks of any application and so it isn't surprising that an effective strategy for the development of good software would start with the principles that should govern the management of this essential commodity.
No comments:
Post a Comment