Development in Dev system?

[Former Member]

Currently where I work, <u>anything</u> and <u>everything</u> new to our R/3 landscape (6.20) is done in a crash and burn box. Therefore all programs I write are manually copied to the development system after proven to function correctly. I'm new to SAP, but this seems inefficient. Their main reason for doing this is they have broken the crash and burn box, and are afraid they'll break Dev. My first questions: What happens if one breaks Dev and how often does this happen to others? I get the impression that most shops develop in Dev. Is that impression accurate? If I am correct in thinking most development should be done in Dev, could anyone please offer some conveying evidence to convince my co-workers? Finally, there is almost no data in our Dev system, which makes possible developments less enticing compared to the crash and burn box which is a copy of Prod. Is there any way to copy only a portion, like 30%, of Prod data into our Dev system? If there is a copy function, does it keep all the proper relationships between the data it copies?

[RichHeilman]

In our landscape, we have 2 boxes, the production box and the test/dev box. All of the development and testing occurs on the test/dev box which is refreshed with current data from production every 3 months or so. I'm having a little trouble understanding how your developers are "crashing" your development box on a consistant basis. That sounds strange to me. As far as copying a portion of the data from production to other boxes, yes, its possible to copy certain data manually at the operating system level, but not recommended. You would never be able to make all of the connections. Its all, or nothing.

Regards,

Rich Heilman

[Former Member]

Hi guys,

In my experience, I`ve worked with a lot of different landscapes. The better to me is 3 boxes. The first one, development, with 3 clients, customizing (no data), development (basic data to developers can do first test to programs), and test (with data to make a good test to programs). The second box is QA, is a copy of prd system, and it should be refreshed one a month for example. And the last box is PRD.

Sometimes, the test client in DEv box and the QA box is the same, or in a client in DEV, or in the QA box.

Never the programs have to be copied by hand... The objects are developed in DEV and then move it to QA and the to PRD via transport request.

Please, ask to your co-workers, to read SAP documentation... Specially to the basis responsable.

Regards,

PabloX.

[Former Member]

Thanks for the reply Rich,

They are not crashing the crash and burn box consistently. They have crashed it a number of times in the past. I'm not sure they know how many times. Let me try an example... Assume that .5% of all work (programming/configuring) causes the system to crash. Their theory is that they rather do all the work to move everything manually from the crash and burn box to Dev just so that the .5% of the work doesn't cause Dev to crash. So my next question would be, exactly how bad is it to crash one's Dev system?

Message was edited by: Dan Miller

[thomas_jung]

This is interesting. What exactly do you mean by crashed. Do you just mean that the system needed to be restarted (no big deal on a Dev Box) or that the system had to be rebuilt (A very big deal).

I have been programming ABAP for 9 years now and I have never seen an ABAP program that cause a system to have to be rebuilt because of a technical problem. I have seen data load programs go bad and load data incorrectly (wrong data in the wrong field or delete data that should have stayed). Then yes the system was restored.

In my experience, there is very little that can be done from within ABAP that can actually bring down a system. I used to know a few programming pot holes that would overallocate memory and bring down a 3.0 based system. However in recent releases of SAP (4.6 and higher) the runtime system is very good at catching things like this.

I actually brought down a 3.0C system by accident at SAP training long ago. I had the following code:

loop at itab.
  append itab.
endloop.

Now the same code just runs for awhile and then gets dumped by the ABAP runtime.

[Former Member]

Thanks for the reply Thomas,

I believe they are concerned that the Dev system will need to be rebuilt. Version management is the main factor for them to tip toe around in Dev instead of doing any development. Does this mean Dev would need to be backed up daily in case Dev was rebuilt? How frequently do most places backup their Dev systems?

[Former Member]

Thanks for the reply Pablo,

I don't think I'd get very far asking my co-workers to read SAP documentation. The first reason is that we are so short staffed, and most don't have any extra time in the day. This is also why I'm doing most of these replies at night on the my own time. The other reason is that the current method technically works. So there's the whole "it's not broke so don't fix it" thinking going on. Finally, I think they find doing hours upon hours of extra work is worth keeping their change management risk free.

[thomas_jung]

Our Basis admins take the Development system very seriously. To them Dev is just another production system (just with a different type of user - the developer). We do full backups via an EMC technology called BCVs twice a day. Also every Oracle archive log is backed up three separate times before it is deleted. Therefore in theory we should have point in time recovery for the development system.

However at the business unit I am working for now, we have never needed to recover our development system. We have two clients - 010 is our golden configuration client (with no master or transactional data) and 088 is where we do our first pass at config and do all of our development and unit testing. From time to time we do delete client 088 and refresh it from client 010. We then use ALE to bring good master data back from our production system. Of course none of this has any effect on our programs or version management because all of that is client independent.

For integration testing, we have our QAS system. This is a separate instance of R/3 that is refreshed via System Copy from Production. Here we have a full set of master and transactional data which we can test with.

[Former Member]

Hi Dan,

This seems really strange. I haven't seen any client so far that does development this way. Even SAP standard recommended landscape is DEV, TEST, and PROD. So, I don't know what is it that happened at your client that effected them so much that they stopped doing development in DEV.

How did they manage to break the DEV system? In a typical landscape, DEV systems have lot less database size than QAS or PRD systems. So my guess is that they might tried to copy production data to dev systems and might have crashed it.

The crash and burn dev system is an inefficient way of doing development. Take a scenario where you have both config changes and development objects that depend on those changes for testing. Are they doing both config changes and development chanegs in the crash and burn system? If so, once tested in here, they are going to redo it in the dev system just for the transport part of it? Isn't that amounting to double the work?

DEV systems are meant for development and unit testing. So they don't need production kind of data. That needs to be in the test system. Depending on the type of data that a particular program is looking for, you can copy portions of certain transactional data. Also, when they copy production to dev they don't copy the whole database, they can avoid copying repository objects and customizing.

I am curious as to why this decision was made.

Regards,

Srinivas

[Former Member]

Thanks for the reply Srinivas,

I'm not sure what happened to the Dev system around seven years ago. I think the system had to be rebuilt. Then again they may just be afraid of that happening, and are taking extreme precautions against it. I like your scenario and completely agree. The trouble I'm having is trying to get them to see that this benefit out weights the small chance of breaking the Dev box. Finally, the decision was made when they started using SAP with just HR and FI. They consider the Dev system a gold system or something to that effect. The biggest concern is that if they don't test everything in a crash and burn box first, they might make a change to Dev that can't be reversed.

[Former Member]

Hello Dan,

I can only tell that at all the clients I worked for, the landscape always had three environments, one DEV, one QAS and one PRD. Now, there were instances where there was a special need for a crash & burn environment at certain times, but that was to test out a specific scenario like a proof-of-concept or to get some emperical data about large data loads etc., but not for ongoing development.

In most places I have seen DEV environment having a golden config client, a config client, a development client and a unit testing client and in some cases a crash & burn client. But these are clients in the same environment. The golden config client stores all the approved config, the config client is where all the changes and new config are done and development client is where the development objects are created/changed and transported. Golden client, crash & burn client and the unit test client are not on the transport path. This way you can achieve some partial impact isolation. But a bad program can always effect every client in the environment. Still, I don't see how that can bring down the system, unless it was a very malicious piece of code that simply wiped out the integrity of the system.

Now coming to the benefits offered by the crash & burn development system you have, I don't see anything as a benefit in it. If you can have a system that you can copy your production data, then you can afford to do the same to your development box, by adding that additional database space on to this box. When you copy production data, you should only copy the data not the config or the repository objects. So this is not a big advantage for the crash & burn system.

Now coming to the isolation of a remote possibility of system crash to this crash and burn system is not much of a benefit either. This can easily be avoided by a disciplined approach to development, stricter authorizations and a good client strategy and may be a back up strategy as mentioned by Thomas.

Now the cons of having a seperate crash & burn system.

You need to maintain a seperate hardware for the purpose which is added cost.

You need to make additional effort to redo(or copy) all config and development objects to the regular development system for transport purposes.

Regards,

Srinivas

[Former Member]

Hi Dan,

This is an interesting question, it has quite a few angles worth considering, I might try and address them in the order which makes sense to me.

<b>1. Data</b>

Having good data for testing your developments is one of the biggest problems I have come across in SAP implementations. In your case, where you are working on a system which has a copy of the production database, I think that you should be happy that you can fully test (even stress test to an extent) all your developments thoroughly.

<b>2. Manually copying to DEV</b>

Why doesn't your company create a transport path between the crash and burn and DEV? This would allow you to transport the work you have done, rather than manually copying it (which just means you have to test it all from scratch again as you are not guaranteed an exact copy.

<b>3. What is your development system for?</b>

If you don't use your development system for development, what do you use it for? Is it just a starting point for transports? If so, then I don't really think you need one.

<b>4. Is it a big deal if DEV is 'broken'?</b>

If dev crashes then who is affected? All the same people who would be affected if your crash and burn system 'broken' (as they would not have a system to develop in).

<b>5. is is possible to do a partial data copy?</b>

Unfortunately (via standard SAP tools) not, you can do some partial copies (such as only users, only config, etc.), but you cannot just copy 1/3 of the transactional / master data. If you think about this I think you could understand why. Which 1/3 would you copy? How would you ensure referential integrity for the data which was copied? This would be a nightmare.

The best way is to spend the time up front and build some high quality test data in your development system and keep it maintained. Its even better if you can have a reference (like an Excel sheet) which you can use to look up which data to use in which scenarios etc.

Anyway, that was long winded but I hope it helps.

Cheers,

Brad

[Former Member]

Thanks for the reply Brad,

1. I agree, this comes in handy.

2. They don't transport for two reasons. One, they don't know how to setup another layer/route and don't want to change anyway because they're afraid of messing up the standard route. Two, no one is confident enough is their transport request knowledge. This means they are not sure what exactly will be transported so they rather start from scratch in Dev just to be sure.

3. That's pretty much it. It's also for version management, which is what I think they are the most afraid of losing/messing if they cause problems in Dev. When I say problems, I mean something so bad that Dev needs to be rebuilt.

4. Exactly, I completely agree.

5. Thanks for the info.

[Former Member]

hi dan,

i also find this approach strange. in our company, we have three development clients (but i'll explain this in detail).

the first one is our development client. it has dummy data, some master data copied/created manually from standard 'templates', but more or less everything is good as nothing.

the second one is our customizing and transport client. we create all our transports and customizing requests here. there's no data in this client.

these two are housed in the same box, and changes in the second box (a program, for example) is carried over to the development client. though i haven't seen it myself, i'm pretty sure customizing requests also take effect for the development client. that way, we can test the customizing entries that are created, yet transport cleanly into our production.

there's a pseudo-third box - our flashcopy. this is an exact mirror copy of our production system as of a certain runtime. we use this primarily for backup, but we use this for testing problems that are encountered in production that we can't replicate in development. and since this is refreshed every so often, we can do pretty much anything we want here.

and i will agree with everyone - i have yet to see an ABAP program that would do so much damage as to render the system unusable. as a preventive, we do backup our DEV servers every so often (weekly or bimonthly or something similarly frequent).

maybe you could use some of the info here.

ryan.

[Former Member]

I really like the sound of using multiple clients for Dev. Has anyone had problems with client independent config and is it even much of a concern? Also, I don't think our crash and burn box only has production data. I think it is built from a full system backup of Prod making them exactly the same for the point in time the backup was done.

[Former Member]

No, we didn't had any issues with client independent config. The way we managed them was by implementing a very good change control. Every intended change will be assessed for its impact on other developments/projects and then all impacted will be notified of the impending change so that everyone will be aware of it and be prepared for it.

If your crash and burn system is a full sytem backup of your production, then won't you be overwriting any under-development objects/config in the c&b system? That means an additional step of making sure that every object/config is tested and is moved to the real DEV system, before rebuilding the c&b system from production backups. If this has to be done often, then imagine how much coordination effort one has to do.

[Former Member]

Hello,

You can do a partial copy of transactional big tables like BSIS, COEP... for instance you can copy only this year (2005) using a data field.

You can do this using SQPLUS or downloading/uploading the table via an abap program. You cannot use R3trans for this, it doesn't work.

Bear in mind that you must exclude the table(s) from client copy.

Fernando Figueiredo