Building Microservices | 12 Factor App | Admin Processes | InterviewDOT

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

Tamil Building Microservices | 12 Factor App | Admin Processes | 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.

Admin Processes
“Run admin/management tasks as one-off processes”
✓ Use the same release bundle as well as an identical environment for both
application services and admin tasks.
✓ Admin code should be packaged along with the application code.
✓ Admin tasks should never be ad hoc and instead should be done via scripts
that are managed and maintained through the source code repository.
✓ Admin scripts should be repeatable and non-changing across each
environment they’re run against.

Run admin/management tasks as one-off processes
The process formation is the array of processes that are used to do the app’s regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app, such as:

Running database migrations (e.g. manage.py syncdb in Django, rake db:migrate in Rails).
Running a console (also known as a REPL shell) to run arbitrary code or inspect the app’s models against the live database. Most languages provide a REPL by running the interpreter without any arguments (e.g. python or erl) or in some cases have a separate command (e.g. irb for Ruby, rails console for Rails).
Running one-time scripts committed into the app’s repo (e.g. php scripts/fix_bad_records.php).
This should be fairly self-explanatory but the key point is to learn to separate out admin/management tasks as scripts instead of trying to incorporate into WordPress (like an admin page for example).

Example: you need to do a search and replace in all posts to update a URL.

Since this is a one-time process it might make sense just to do it directly through the console, or right in MySQL. But it's often better to write a script that will be committed to your codebase. This gives you a history of them and it's easy to copy it for a different task later on.

Admin processes: - Run admin/management tasks as one-off processes
There are many reasons you might need to run a one-off task within your application. Some tasks such as running migrations or packaging static assets are done at release time. Other items such as cron jobs or maintenance scripts are run as part of the everyday function of your application.

The critical principle is that these tasks should not be run on the same processes that are handling your everyday traffic. Instead, you should fire up a one-off process using an identical release (code+environment) to prevent one off tasks from causing issues with your running applications. If you take this approach one step further you can run a one-off tasks against any release, including a release that is not yet promoted, which allows you to do things like run migrations before you release allowing zero-downtime deploys.