Hi,

Was thinking throughtout the new year night <g>. Your concepts I can get some (in my layout) and use some. Like you said all this is a long process, thus initially I won't stop building. My directory structure is as follows:

C:
+---VSO2 (Deve dir)
      +----Lib  (Framework dir) etc.
      +----SW (All apps dir)
            +-----A09  (App dir contains the EXE)
                   +----CMP00001 (Data dir)
                   +----SPRS (screens)
                   +----PRGS (progs)
                   +----MPRS (menus)
                   etc.
                   +----VSOSYS (project dir)

Now as I was thinking, !!!phew!!!, the per client directory structure as and when required. This follows:

C:
+---VSO2 (Deve dir)
      +----Lib  (Framework dir) etc.
      +----SW (All apps dir)
            +-----A09  (App dir contains the EXE)
                   +----CMP00001 (Data dir)
                   +----SPRS (screens regular production files)
                   +----PRGS (progs regular production files)
                   +----MPRS (menus regular production files)
                   etc.
                   +----VSOSYS (project dir)
                   +----GBLSYS (project directory using client initials as I already maintain them)
                         +----SPRS (screens, optional as and when required)
                         +----PRGS (progs, optional as and when required)
                         +----MPRS (menus, optional as and when required)
                         etc.
                   +----AISYS (project directory using client initials as I already maintain them)
                         +----SPRS (screens, optional as and when required)
                         +----PRGS (progs, optional as and when required)
                         +----MPRS (menus, optional as and when required)
                         etc.
                   etc.

These are just theories yet. Now VSOSYS my project directory is the main stream app whose project is what I will want to distribute under regular circumstances and for emergencies. GBLSYS for eg. is the directory structure of my client GBL and will contain only the required files, as this project is on the same level as VSOSYS it will automatically find files which are still in common. The sub-dirs under GBLSYS will contain files that may be sort of checkedout for development from the regular dirs. Just a thought in between instead of GBL I can maybe have a code for the release note no. that you had mentioned.

So when I compile using the dir GBLSYS the build is for, in this case, my client GBL and I deliver to him only. Now client XYZ comes along with an urgency I compile from VSOSYS my regular app and deliver it to him. Once I am through with say client GBL (or R.N. code) I have the task of merging the checked out modules into the main stream app. This might create problems as I might have modified a same named file during the urgency request of XYZ but here I guess FC from DOS will be handy. Once merged the GBLSYS directory will be removed until required again.

As far as data structures are concerned I will only have one CMP00001 and taking your adivse I'll one add and increase size where client dirs are concerned.

These thoughts started at 1:00am and ended at 8:00am with a lot of sleep inbetween, so I guess there may be a lot of holes to be plugged in this scenario. What I am counting on is that becuase my original dir structure is not disturbed, so worse comes to worst, I'll be able to start of from where I last stopped.

Please advise and let me know if I have to clarify a point. Could you give me a critical evaluation of my derivations of your convcept.

>Hi !
>
>Solution #1 : have your code bug-free ... {g}
>Since this can't be done, let's have solution #2 :
>
>There aren't many developers that implement general requests of customers into the one package. In fact, you are the second I've heard of, and we overhere were the first. Okay, there will be more I suppose, but it will be very few.
>
>So we do it too, and it needs quite another approach of about everything.
>Let me first show you our situation a little :
>
>We have over 7,000 prg's, a bunch of (visually created) classes, over 1,400 tables, and a handful of physically separated subsystems (logistics, financials, "system", etc), but 100 % integrated when all is installed.
>The system conists of about 85 functional modules, and not any customer has the all, and the chance that any two customers have the same combination is small.
>Do you think you can make a build for this ? never.
>
>Each other week, we add/change 100 - 150 functions (prg's), which is (let's say) for 90 % about customer requests, and 10 % solving bugs. BTW, the bugs can obviously be about the last custom work, but can just as well be about something 10 years in there, but nobody used so far.
>Of course, bugs can be about business functions, but can also be about systems functions (or the "framework" if you like). The impact of the latter is the highest, obviously.
>
>In general, 5 - 10 upgrades per day are downloaded by all the customers together.
>
>So these are our surroundings.
>Now our regulations to let this all work :
>
>
>Anticipate 100 % on never building anything anymore. With the larger app it can't be done anyhow, but it allows you to upgrade only those functions, to those customers who need it. This may come indeed to only uprading the customers who asked for the function.
>Note that there may be much to this, and that the app possibly don't allows for just stop building, and have all the individual functions at the customer's site. Your app may be too slow or whatever, but it will come to the same as the DE environment. So you know what you have, and you can see what needs to be changed. Just remember : we do it like this, and according to speed there is no problem at all, though you must apply lots of things to let it all work okay.
>
>Now where the above is the basis for what you need, there is more to it. However, it is not much different from what you needed anyhow, but didn't apply yet;
>
>You need some subsystem in order to keep track of logical sets of amendments. I.e., when a customer requests for some new function, you may need to amend some menu's and other related functions, and during your working on the new function, another customer may want an upgrade. What you do right now, is postponing the build until all is ready, and the other customer just gets the old build. This changes now, because you won't have a build anymore.
>The dirrence is small, because now you'll have different directories, one for development, and one for production (per subsystem as with us).
>
>Your logical set of amendments, will go to production only when the whole set is said to be ready.
>The subsystem arranging this, isn't the most easy piece of code, thinking of many developers working on the system as a whole, and one touching programs the other touches too, but for a different reason, i.e. another logical set. We call this a Release Note. So, one developer works on this Release Note, and the other on another Release Note, and both Release Notes may contain the same program(s). This implies that a Release Note can be said ready, but still can't go to production because of not being consistent to the other Release Note, which isn't finished yet. With eyes closed this will lead to dead-locks, but which are not at all, because the code dealing with this must be more intelligent (just think of it, there can't be infinite deadlocks at all). However, what can happen, is that a Release Note is rather forever waiting for getting to production, because each other day a developer may start another Release Note containing the same program(s) as the waiting Release Note
>again.
>
>The above may require this code to run in some batch environment, because many has to be sorted out once a Release Note is indicated as ready. The developer doesn't want to wait for that.
>Note that a batch environment can be easily created within WTS and some task permanently running there, picking up jobs to run. We do this. Can be a dedicated PC just as well.
>
>So the above you needed anyhow, and I think you recognize it.
>Now watch it :
>
>Overhere, we don't apply what you want in the end : wait until custom work is bug-free and only then send it to the other customers. Okay, occasionally we have the same at hand, and at that moment just nobody is allowed to download upgrades. Upgrades btw, which are always incremental only. I.e., always sending the complete app is stupid, and another functionality will be needed in your upgrades subsystem. "Know which customer received what and when".
>The "reason" we don't apply your needed function "postpone upgrades until bugfree" in general, is because we work rather bugfree indeed. I know, it's stupid to say (from one's self) but we work like this anyway, and the customers are 100 % depended on the app (it's ERP), so there must be some truth in there; We just do it.
>
>Now Bhavbhuti, just "learn" that once you allow yourself to have upgrades each other day, the developers need to work bugfree indeed. Or IOW, it would be the most easy for this environment, and another way of working hardly allows for upgrading the one package with all customer requests. Again, you may be the second working like this, which may mean that this world hardly has the experience on how to deal with this. Or differently : it can't be done (work bug free) so have the custom work as custom forever. And, have a yearly upgrade of the package, after extensive testing.
>
>What I won't tell you, is that you need to extensively test all your custom work, because that can't be done too. Just takes too much time;
>So we don't test at all and throw the bugs to the customers each day ? in fact yes, but for the bugs, because they just aren't there, except for some exceptions. Now note that the whole way of working is just another system within itself, because what happens ? when there is a bug, you solve it withing 10 minutes, and the next minute it's at the customer. So what I say is, because you don't have the build, you can start thinking of sending any single program to the customer, and it takes the time to download (or upload) only. This really makes a difference !
>
>We advise our customers not to wait with upgrades until over two months, because too many things will be changed at the one time (for them), and too many bugs will possibly be encountered. What do I say ? that there may be too many bugs to solve withing the "promised" 10 minutes.
>Now note this too : at the custsomer's site there may be this DE-environment (for them, and it will contain the last production environment but for test-purposes). This is an option the customer can choose for, and almost nobody has it (wants it). Why ? because it gives the responsibility of extensive testing by some system manager, and which really takes a job time, because of so many things changed each time. But note that for you this may be (part of) the solution !
>
>So, whereas we allow ourselves to upgrade an un-tested system to the customers (almost explicitly approved by them because of not wanting the DE environment !) for you this may be nothing. BTW note that the testing at us really isn't needed because of 100 % working in objects not being related to other objects but for (100 %) decent inheritance. So in there is the solution to few testing : test the one object only, and don't (need to) test the combinations with other objects (which can't be done anyhow because of far too many combinations). Well, let's assume you can't cope with this :
>
>The earlier described Release Notes can be extended to be unique per the customer requesting for it. Just look at this as the developer having a Release Note, but now the customer has it (too or so). Now when the Release Note is said to be ready, it is ready for this one customer only, so it goes to this one customer only. So we don't do this, but it could easily be done by having temporary directories per customer, and when a customer needs an upgrade, he's receiving the general (one) directory, and his custom directory (always incremental stuff only). Now at some time you'll see that the custom work is approved (no nugs reported, or you solved them), and the other level of saying that the Release Note is ready (system level now), will implement that in the general production directory and the Release Note ('s functions) is removed from the custom directory.
>
>
>Bhavbhuti, the above is hardly anything you can implement within due time, because we are working on this for 10 years or so (throughput) and we are just about ready to let the customer download an upgrade via Internet, us not even knowing that that's happening;
>All is transparent to the developer anyhow, who's just creating Release Notes and saying that it's ready at some time. That's all. Modify Command (etc.) all goes via functions, in order to registrate the according in some tables, the batch process picking things up and doing the remainder.
>Where I speak about functions/programs, there is more to it, like upgrading the database, which is always done with our latest (DE) version, thus unaccording the functions upgraded. Can that be done ? yes it can, but this again needs another way of working which comes to never deleting fields and adding only. Or, never making fields smaller, and only make them bigger. Note that this aint a rule at all, but follows from some really normalized way of working, which' explanation goed far beyond this Thread;
>
>The only thing I wanted you to know is that what you want, really can be done, and I hope to have given you some guidelines with the above. Please "know" that there will be far too much to it in order to create this whole environment within due time. We see this as our "skill", and we live by it, because indeed the customers create the package. So one pays, and all others benefit, but the paying benefits just as well because of others paying. And we like it too.
>Well anyway, you'll recognize this, because you do it too.
>
>What you, however, always should do, is stop building, and have incremental upgrades, allowing you to differentiate per program who receives what and when. From that slowly the rest may follow. But it takes some years ...
>
>Good year-endings !
>Peter
>
>
>
>
>>Sub.: FPD25 App Modification Versioning/Management between multiple sites.
>>
>>Hi All,
>>
>>I have an app for which there are multiple clients. There are times when a change ordered by client A, is later installed for client B. Now this new code breaks and the client B also suffers unnecessarily. Now the thing is, changes made for client A when successful will be loved by client B. Client B just does not want to have it until it is bug-free.
>>
>>This is a simple situation, in reality there may be a couple of different changes being made for different clients concurrently, in the end all of them will receive all these changes, but in the interim till a given changes thread is not bug free I do not want to pass-on these changes to other clients who have not ordered the changes. Yet I have to generate builds for deployment as well as develop and fix as required. How do I avoid such a situation?
>>
>>Currently I have one directory for development, here I do the R&D. There is another directory for deployment where my last release build is stored and from this I generate the distribution disks and pass on to the clients. Thus I am able to avoid atlease one level of this problem. But when there are things that break long term, there comes a time when almost all clients have it and all of them go down together.
>>
>>Any changes I make, down the line I will want to inlcude them in the main stream app. I cannot maintain multiple development copies and how can I manage so many and how to merge them in the end. Documentation is scant if at all available. There are also times when a change is mandatorily required to be done for all clients concurrently.
>>
>>At times I have a deployment build ready and under the development directory I am making heavy changes, which, until completed cannot be relesed. Now a client comes along with a serious problem (see my original problem above <g>) which I *have* to fix and my hands are tied due to the current changes that are being made.
>>
>>Now what happens is that I will convience my client that due to such circumstances the fix will be delayed for a couple of days and the goodness of the client is that he agrees with it. Now due to time-constraints (he still want it yesterday and calls me up everyday for it), the current un-stoppable work may suffer in quality if a few corners are cut or forgotten, just because the important fix is to be relesed and delivered to all affected.
>>
>>This starts another cycle of the problem as I have had to compulsorily deliver a change due to a required fix before I was personally satified with the quality of the change.
>>
>>Can anyone suggest a way to go about this or is anyone facing such problems and has solved it or atleast has an idea to solve it, anything, anything, just let me know.
>>
>>If I have not been able to clarify my thoughts please let me know and I'll explain what I meant.