Application Environments
-
I am sure this must have gone round before but, how many environments do you have / think is necessary? We have quite a collection of inter-related systems here, in-house developed, off the shelf, heavily customised, and using a number of different languages and databases. Some only exist in live, some have dev / test and live, most of our stuff has dev, test and live. The new daddy system that is yet to go live and needs to interface with most of the others has been setup with dev, test, train and live. Just had the bloke in charge of this project come to see me quite panicky because he has realised that he doesn't know how to use these environments properly or what they are going to talk to with respect to the other systems. Training starts at the end of this month whilst I am on holiday :-D. I think it would be best if we had at least a nod at the same number of environments for each system as they all have to work together. So, bearing in mind that all the systems we write or support are for our own group of companies, what environments would you recommend? I think 3 is a minimum, I cannot decide if the 4th is necessary or not. Previously I worked with dev, 8 test / train / whatever, and live. Which worked well, but then we only had the one system to support then. I have also worked with 5 environments, although I can't now remember what they all were, dev, test, qa, prod, I am sure there was one other.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
I am sure this must have gone round before but, how many environments do you have / think is necessary? We have quite a collection of inter-related systems here, in-house developed, off the shelf, heavily customised, and using a number of different languages and databases. Some only exist in live, some have dev / test and live, most of our stuff has dev, test and live. The new daddy system that is yet to go live and needs to interface with most of the others has been setup with dev, test, train and live. Just had the bloke in charge of this project come to see me quite panicky because he has realised that he doesn't know how to use these environments properly or what they are going to talk to with respect to the other systems. Training starts at the end of this month whilst I am on holiday :-D. I think it would be best if we had at least a nod at the same number of environments for each system as they all have to work together. So, bearing in mind that all the systems we write or support are for our own group of companies, what environments would you recommend? I think 3 is a minimum, I cannot decide if the 4th is necessary or not. Previously I worked with dev, 8 test / train / whatever, and live. Which worked well, but then we only had the one system to support then. I have also worked with 5 environments, although I can't now remember what they all were, dev, test, qa, prod, I am sure there was one other.
Every man can tell how many goats or sheep he possesses, but not how many friends.
ChrisElston wrote:
how many environments do you have / think is necessary?
As many as needed to solve the business needs of the company.
ChrisElston wrote:
I think 3 is a minimum, I cannot decide if the 4th is necessary or not.
For me "dev" would mean what is on my box and nowhere else. This of course would be necessary. "prod" is where the business makes money. So it is necessary. Anything else is optional. A "test" one is only reasonable if it is in fact used. And used consistently. This can often require dedicated QA. You didn't mention "build" which is something I prefer. It is doable in "dev" but I prefer that everything is blown away first and that is problematic on "dev". As for "train" that presumably would be a mirror of "prod" with less control and need for stability. Some businesses would require it. It can be available in house and/or externally. It would require a business driver rather than a development process driver. You can also have "integration test", "system test" and "user acceptance test".
-
I am sure this must have gone round before but, how many environments do you have / think is necessary? We have quite a collection of inter-related systems here, in-house developed, off the shelf, heavily customised, and using a number of different languages and databases. Some only exist in live, some have dev / test and live, most of our stuff has dev, test and live. The new daddy system that is yet to go live and needs to interface with most of the others has been setup with dev, test, train and live. Just had the bloke in charge of this project come to see me quite panicky because he has realised that he doesn't know how to use these environments properly or what they are going to talk to with respect to the other systems. Training starts at the end of this month whilst I am on holiday :-D. I think it would be best if we had at least a nod at the same number of environments for each system as they all have to work together. So, bearing in mind that all the systems we write or support are for our own group of companies, what environments would you recommend? I think 3 is a minimum, I cannot decide if the 4th is necessary or not. Previously I worked with dev, 8 test / train / whatever, and live. Which worked well, but then we only had the one system to support then. I have also worked with 5 environments, although I can't now remember what they all were, dev, test, qa, prod, I am sure there was one other.
Every man can tell how many goats or sheep he possesses, but not how many friends.
In a previous life, we had one system (as in "app", but it was mainframes not PCs). Three copies - dev, test, prod. (Oh, and test was hot standby for prod. Testers knew that their system could disappear at the drop of a hat if prod hardware chucked a wobbly.) All worked fine until a second system was brought in (which of course had to interface with the first one). After a while, it became obvious that we needed another test copy of each system. Basically, to test a change for system A (which is going in as an isolated change, not a big-bang upgrade), you need a clone of system B prod. This is different from B test, where the B testers are playing with new stuff which will go into B prod down the track. We wound up combining that integration testing function with user training, which wasn't ideal but did save the odd megabuck's worth of big iron. Just my two bob. Peter
Software rusts. Simon Stephenson, ca 1994.