Some might be confused about these 2 definitions, but if you work with Microservices long enough, you will see this is easy to understand.
For example, one workspace can have many projects, one project can have many child applications, such as: front-end, back-end, API gateway, database, this service, that service, blah blah blah…
Simplify those “micro-services” into projects & apps make it more “developer friendly” and obviously improve developer experience (dx)
It is the environment where your apps are deployed to!
When deploying to "other environments", your app will be visible to the public immediately. However, when you deploy to the "production" environment, it will only be visible in the "prerelease" environment and will only be rolled out to the "production" environment intentionally.
Check out this “Blue Green Deployment” flow:
Basically this is what happens when you deploy your app to production environment
This is the main different of production environment with the other environments, think about it like a previewed version of your production app. Take a look at the comparison below:
| Prerelease Environment | Production Environment |
|---|---|
| • New build | |
| • Same Kubernetes cluster | |
| • Same Kubernetes namespace | |
| • Same environment variables | |
| • Different Kubernetes pods | |
| • Different access URL endpoint | • Old build |
| • Same Kubernetes cluster | |
| • Same Kubernetes namespace | |
| • Same environment variables | |
| • Different Kubernetes pods | |
| • Different access URL endpoint |
So basically the prerelease environment is the same with production environment.
<aside> 👉 Why? The purpose of this workflow is to ensure that your "prerelease" app undergoes a full test without any bugs, errors, or typographical issues. Once you have completed this process, you can confidently roll out your app to the public in the "production" environment.
</aside>