Open-Source Internship opportunity by OpenGenus for programmers. Apply now.
In this article, we explore if developers should have access to production and the solution that is used in real life.
Note: Production refers to Production Server and not just the codebase.
Production Server = Production Hardware + Codebase + Server logs +
Database
Developers need access?
On the one hand, developers need access to production servers to be able to debug issues that may arise. They also need to be able to deploy code changes and monitor their performance in production. Without access to production servers, developers would be working in a silo and would not be able to effectively do their job.
On the other hand, giving developers access to production servers can be risky. If they make changes to the code or configuration, it could potentially break things for everyone else. In addition, having too many people with access to production servers can make it more difficult to track what changes have been made and when.
What is the best solution?
The best solution is:
- Maintain 2 or more mirror of production server
- If production fails, users are redirected to one of the mirror sites so your business continues as usual and meanwhile, your developer team debugs the issue. Make the mirror your permanent site and make the previous production as a mirror.
- Developers may have access to one of the mirror site server and can try their changes on this server.
- Developers may need server logs but do not need real database.
- More the developers having access, more is the risk of information leak.
- Always maintain a automatic back-up server.
The best solution comes at a price and works on the principle of redundancy and low access and works perfectly. Not everyone can bear the cost so at minimum, maintain just a automatic back-up server.
The answer depends on your organization's size, culture, and structure. If you have a small team of developers (mostly co-founders) working on the same codebase, giving them access to production servers might make sense. This way, they can quickly make changes and see the results in real time.
If you have a large team of developers, or if your developers are working on different codebases, it might make more sense to have a separate group of people responsible for deploying code to production servers. This way, you can avoid having too many people with access to production servers and more easily keep track of who made what changes and when.
The main thing to remember is that there is no one right way to do things. It depends on your specific situation and what will work best for your team. So, take some time to think about what would work best for you, and then decide accordingly.
