0

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?

Improve this question
6
  • Those aren't tiers. What does your SDLC look like now? What "stages" do you currently implement? Surely you don't smoke-test your fixes and new features on the production server. Commented Dec 29, 2014 at 1:08
  • @RobertHarvey you will have to forgive me for not using the correct terminology in regards to the word "tier" although I think the thrust of my question remains. I am not a BI Developer, just merely educating myself incrementally. Commented Dec 29, 2014 at 2:19
  • My use of 'tier' seems appropriate given this highly rated answer programmers.stackexchange.com/questions/114620/… Commented Dec 29, 2014 at 5:01
  • 2
    Don't get stuck on the word "tier." Yes, tiers are hardware. No, they don't describe the Develop, Test and Production phases of an SDLC. Read the Wikipedia article; multi-tier architecture is a client–server architecture in which presentation, application processing, and data management functions are physically separated. A three-tier architecture is typically composed of a presentation tier, a domain logic tier, and a data storage tier. Commented Dec 29, 2014 at 5:46
  • 1
    Regardless of how any single person or question might use the term "tier," that word has a specific meaning in the context of these types of applications. I reworded the question to use "stage" instead which more accurately represents the intent of the question while removing ambiguity with the more common definition of "tier" in this context. Commented Dec 29, 2014 at 15:47

2 Answers 2

Reset to default
5

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).

Improve this answer
1
  • 1
    tl;dr: PC's are cheap. Developers are expensive. Letting your customers find your bugs for you is priceless. Commented Dec 29, 2014 at 1:24
1

There are some benefits of doing maintenance in Production:

  1. Spares time for the developers.
  2. 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.

  1. Create a backup from the Production system (the basis team gets some practice)
  2. 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)
  3. 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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.