Building Microservices | 12 Factor App | Dev/Prod Parity - Dev, Prod Similar Setup | InterviewDOT
Channel: Interview DOT
Date: 2020-04-09

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

Tamil Building Microservices | 12 Factor App | Dev/Prod Parity - Dev, Prod similar as possible | 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.

The tenth of the 12 factors, dev/prod parity, instructed us to keep all
of our environments as similar as possible.
While some organizations have done more evolving, many of us
have likely worked in an environment like this: the shared develop‐
ment environment has a different scaling and reliability profile than
QA, which is also different than production. The database drivers
used in dev and QA are different than production. Security rules,
firewalls, and other environmental configuration settings are also
different. Some people have the ability to deploy to some environ‐
ments, but not others. And finally, the worst part of it all, is people
fear deployment, and they have little to no confidence that if the
product works in one environment, it will work in another.
When discussing the design, build, release, run cycle, I brought up
the notion that the “It works on my machine” scenario is a cloudnative anti-pattern. The same is true for other phrases we’ve all
heard right before losing hours or days to firefighting and trouble‐
shooting: “It works in QA” and “It works in prod.”
The purpose of applying rigor and discipline to environment parity
is to give your team and your entire organization the confidence
that the application will work everywhere

Time
In many organizations, it could take weeks or months from the time
a developer checks in code until the time it reaches production. In
organizations like this, you often hear phrases like “the third-quarter
release” or “the December 20xx release.” Phrases like that are a warn‐
ing sign to anyone paying attention.
When such a time gap occurs, people often forget what changes
went into a release (even if there are adequate release notes), and
more importantly, the developers have forgotten what the code
looked like.
Adopting a modern approach, organizations should strive to reduce
the time gap from check-in to production, taking it from weeks or
months to minutes or hours. The end of a proper CD pipeline should
be the execution of automated tests in different environments until
the change is automatically pushed to production. With the cloud
supporting zero-downtime deployment, this pattern can become the
norm.
This idea often scares people, but once developers get into the habit
of coding knowing their code will be in production the same day as
a check in, discipline and code quality often skyrocket.

People
Historically, the types of people deploying applications were directly
related to the size of the company: in smaller companies, developers
are usually involved in everything from coding through deployment;
whereas in larger organizations, there are more handoffs, and more
people and teams involved.
The original 12 factors indicate that the developers and deployers
should be the same people, and this makes a lot of sense if your tar‐
30 | Chapter 9: Environment Parity
get is a black-box public cloud like Heroku; but this practice falls
down when your target is a private cloud within a large enterprise.
Further, I contend that humans should never be deploying applica‐
tions at all, at least not to any environment other than their own
workstations or labs. In the presence of a proper build pipeline, an
application will be deployed to all applicable environments automat‐
ically and can manually be deployed to other environments based
on security restrictions within the CI tool and the target cloud
instance.
In fact, even if you are targeting a public cloud provider, it is still
possible to use cloud-hosted CD tools like CloudBees or Wercker to
automate your testing and deployments.
While there are always exceptions, I contend that if you cannot
deploy with a single press of a button, or automatically in response
to certain events, then you’re doing it wrong.

Every Commit Is a Candidate for Deployment
It’s been discussed at length in this chapter, and you’ll see this partic‐
ular rule mentioned a number of times throughout this book. Every
commit is a candidate for deployment.