Building Microservices | 12 Factor App - Strictly separate build and run phases | InterviewDOT
Channel: Interview DOT
Date: 02/04/2020

Click here - https://www.youtube.com/channel/UCd0U_xlQxdZynq09knDszXA?sub_confirmation=1 to get notifications.

Tamil Building Microservices | 12 Factor App - Strictly separate build and run phases | InterviewDOT

The twelve-factor app methodology is a methodology for building software-as-a-service applications. These best practices are designed to enable applications with portability and resilience to be deployed to the web.

The 12 Factor App Manifesto gives some recommendations on how best to develop web apps for the cloud. A good SaaS application must be easily scalable, quickly deployable and easily portable. However, this is not so easy to guarantee. However, the standards proposed by the manifest are not applicable to all applications.

A 12-factor app relies on the explicit existence declaration of all dependencies, completely and exactly, via a dependency declaration manifest. And you must also use a dependency isolation tool along with dependency declaration.

Build, release, run
Strictly separate build and run phases
A codebase is transformed into a (non-development) deploy by three phases:

The build phase is a transformation that translates a code repository into an executable code bundle called a build . Based on a code version of a commit that was defined in the deployment process, it gets dependencies , packages them for delivery, and compiles binaries and assets.

The release phase takes over the build from the build phase and combines it with the configuration suitable for the deploy . The release created in this way contains both the build and the configuration and can be executed directly in an execution environment.

The run phase (also called “runtime”) runs the app in an execution environment by executing a lot of the app's processes against a selected release.Code becomes a build and together with a configuration results in a release

The twelve-factor app strictly separates the build, release and run phases. It is not possible to make code changes at runtime because there is no way to send those changes back to the build phase.

Deployment tools usually offer release management. The best known is to reset the function to an earlier release. For example, the deployment tool Capistrano saves releases in a subdirectory by name releases. The current release is a symbolic link to the current release directory. With the command rollbackyou can quickly and easily revert to an earlier release.

Each release should have a unique release ID, such as a timestamp of the release ( 2011-04-06-20:32:17) or a serial number ( v100). Releases are never deleted and a release cannot be changed once it has been created. Every change creates a new release.

Builds are initiated by the developers of the app when new code is deployed. In contrast, execution can take place automatically at runtime when a server is rebooted or a crashed process is restarted by process management. Therefore, the run phase should be limited to as few moving parts as possible, because problems that keep an app from running can collapse in the middle of the night if no developers are available. The build phase can be more complex because errors are always visible to the developer who drives the deploy.

Build, Release, Run
“Strictly separate build and run stages”
✓Strong isolation between Build, Release, and Run:
- Build Stage, compiling and producing binaries by including all the assets required.
- Release Stage, combining binaries with environment- specific configuration parameters.
- Run Stage, running application on a specific execution environment.
✓ The pipeline is unidirectional, so it is not possible to propagate changes from the run stages
back to the build stage.
✓ANTI-PATTERN, Specific builds for production.
SUGGESTION = Go through the pipeline.
✓ANTI-PATTERN, Make changes to the code at runtime.
SUGGESTION = Any change or set of changes must create a new release, following the
Pipeline: Build - Release - Run.
✓ SUGGESTION = Every release should always have a unique release ID, such as a timestamp of
the release such as 2011-04-06-20:32:17 or an incrementing number such as v100.
✓ BUILD = codebase + dependencies + assets
✓ RELEASE = BUILD + config
✓ RUN = run process against RELEASE
✓ ROLLBACK = just use the last release instead.

Build, Release, Run: The phases of building and using the app are strictly separated.