I have recently joined a team in which the developers were able to work completely in live production to produce business intelligence products for customers.
Recently, management, at the advice of SAP, have moved the team to a 3 stage environment
- Develop
- Test
- Production
which require transports between each layer.
The team have accepted this new constraint begrudgingly and no firm business case has been explained to them as to the benefits.
Can anyone articulate the advantages of the 3 stage environment or point me to a white paper/case study they recommend?
6
Deploying newly developed features straight into a live production system is extremely risky, in whichever language or platform you choose, because you are not able to test the new features or changes before the current users of the system are exposed to them.
With this in mind, it becomes clear why you should at least separate production and development environment, and choose appropriate times to deploy (transport) from development to production.
However, there are also good reasons to separate even further, and have a testing environment as well. Since complex systems usually require manual testing to completely check it (which may even be done by a team of testers and/or the customer), having a separate test environment allows you to have a stable build of the system for manual/integrated/acceptance testing, while the development is free to continue at its own environment. By “stable”, not only it means that the features were already unit-tested by the developers (at the development environment), but also for SAP R/3, it means that there will be no dumps because someone is activating development objects while there are users running them (LOAD_TYPE_VERSION_MISMATCH).
1
There are some benefits of doing maintenance in Production:
- Spares time for the developers.
- Data for testing is available in production.
The management will not care about the first one, the cost of your (and your colleague’s) time is usually insignificant compared to the cost of a production down.
Creating a Development system helps mitigating the risk, but will not provide you with test data. Copying it from Production is long and tedious. Developers usually create 3-5 lines of test data, so only functionality is tested, but not performance.
This is why a Test system is useful, even the creation process is beneficial.
- Create a backup from the Production system (the basis team gets some practice)
- Restore it to another hardware (many SAP customers only do backups, and have no idea how to restore, so this practice is even more important)
- Now you have a system with actual production data, repeat it every quarter
So all three systems have a different purpose. Production is obvious, Development is the one where developers can experiment and fail without consequences, and Test is where you find out why HASHED tables were developed.