There are three different environments that you'll probably deal with at some point. Each environment has its own properties and uses and it's impo...
For further actions, you may consider blocking this person and/or reporting abuse
We use docker so for us is really easy to replicate an environment on our PCs and Mac.
And we usually have 4 of them:
QA is really important, as we usually clone the filesystem and database of production and use this environment to test what will happen when we build the backend with a Git tag. We can update QA with the tag, run tests, have some people log in to check if everything is ok then we can rebuild the container for production.
I know some companies name the environments differently, so Stage is similar to production and QA is the unstable env. Some others use names like "pre production" or "acceptance" for the last env before production.
It is however important to have at least 3 environments not counting the dev one
thanks for sharing.
Thanks for this article, I found there the environment names that I often read about in various articles.
In our team we have
Where production is clear, release is a version for clients and testers like a copy of production with new things, hotfix is to test some fast fix in case we find something on production, that needs to be fixed fast, feature is to be able to publish for test some special feature, that needs to be tested on the server or by product manager before it goest to release (used rarely only if needed) and dev is for the developers, where they can try various things - from testing speed of the server, trying the migrations and so on. Or just as another host to publish work (for project manager) if all other hosts are already occupied.
So the names conventions are different, but the idea is similar. I was interested what the "stage" or "staging" means.. As I understand it is like the "release" of ours ;)
thanks for sharing
let me throw a another one here "QA Environment"
Basically, everything related to testing will happen here including Feature Testing, Exploration Testing, Build Testing, Regression testing etc..
Once we are sure about the release build, we move it to Stage.
My Team has
Stage environmentbut we treat it as a Locked environment and is houses same configurations and code as Production Environment. We use it as copy of current released build and to compare behavior of various user stories of QA.Test data on this environment should be also as close as actual production so that end users (clients) can have proper demos / training on this one before actually doing anything on production.
Once release build moves to this environment, Every tests must pass here, with 0 Bug count.
Perfect article for a Python data noob going into production (after staging these past 2-3 weeks)... "DevOps" FTW!👍
This article does an excellent job of highlighting the critical differences between the development and production environments. Understanding these distinctions is essential for any developer to ensure a smooth transition from coding to deployment. The emphasis on flexibility in development and the need for stability in production is particularly insightful. It's also great to see the mention of local configurations and the importance of version control. These points are often overlooked but are crucial for maintaining a productive and error-free workflow. Thanks for the clear and concise breakdown!
In software development, Development, Stage, and Production are key environments, each serving a specific purpose.
Development is where developers build and test new features. It’s a safe space for experimenting and making changes.
Stage (or Staging) is like a dress rehearsal. It mirrors the production environment, allowing final testing to ensure everything works as expected before going live.
Production is the real deal—this is where the live version of the application runs, and users interact with it. Changes here directly affect the end users, so it's crucial everything is perfect.
To know more about top software development companies in USA, check out mobileappdaily's comprehensive directory
This is your workshop. Here, developers bring the rollercoaster idea to life. They write the code, design the features, and test basic functionality like if the carts roll properly (on a smaller scale).
Think of it as building the rollercoaster frame in the back room. There might be bumps and adjustments, but it's not ready for the public.
Once the basic structure is built, it's time to take it to the testing grounds. This is the staging environment.
Here, the rollercoaster gets a thorough inspection. Testers ride it, checking for smoothness, safety, and ensuring it can handle the expected weight (number of users).
You might even invite a small group (beta testers) to try it and give feedback.
Basketball Stars Unblocked is the perfect game for quick bursts of basketball fun, anytime, anywhere.
Nice share
Hey this post is great. I also need another clarification. What's the difference between a local and development env? Are they same or has a difference?
In our team local and dev are not so much the same, because dev is to test the server environment - such as speed/performance of the server. Ofcourse also in case the local and server configuration is different - which is a thing that now disappears if you use Docker, but mainly it is about to test the real performance of the server or the process of upgrading production with new version... But what local and dev have the same is that it is a playground for the developer(s).
If you have two different environments with the same information. How you can confirm that we have the same amount of elements in between two of these environments?
This article has been very beneficial. It feels like all of the conversations I had in the past about building, testing, and deploying apps make sense now.
Thanks for sharing!
I think this is a great explanation for those that might not be familar with the 3 stage setup.
My teams use the same approach, we also use Git branches for each environment to keep things simple.
Very well written article! Thanks for sharing it with the community.
Clear and easily understandable.
Thank you so much for sharing the information.