Hi Evgeny

Fascinating conversation.....

I am aware of projections but don't use them in my systems.
I think there is some confusion when I use the term "Test" server  - in my usage this is used for End User Acceptance testing and there are usually more than one project/release undergoing End User Acceptance Testing at any one time - copying the Cache.dat would take over releases that are not ready to go.

= =

I guess it depends on the nature of the operation - I work for individual clients rather than having a monolithic product - and (as above) there will be several projects on the go at each time for each client - so what I do works for me.

If there is a possible problem with the compile (your projections) then, I think, the solution is a staging server - where individual releases are deployed to this and once proven that cache.dat is copied to the Live

My method works in my situation 
I guess there is no single "correct" solution that will work for all cases.

Peter

Hi Evgeny

What situation do you have in mind that could cause the compilation to be unsuccessful?

With proper version control and release procedure this has rarely happened in my experience - when it does it's been due to unresolved dependencies - and in this case a re-compile fixes it.

There is one possibility where it *could* happen - that is if the VC system allows multiple reservations/branches for the same class - bet we don't allow that.

= =
I can't see how deploying/copying the Cache.dat will avoid problems when you have multiple developers or multiple projects on the test server.

= =
I guess the only 100%  way is to have a staging server where a deployment can be copied to and tested before deploying to the Live server - in this case it is tightly controlled and copy the Cache.dat is possible

Peter

Just realised that copying the Cache.dat is only sensible for a single developer
If you have more than one developer working on different projects all deploying to the same Test server then copying won't work - you would get bits and pieces from different projects

Even for a single developer it's a bit dodgy - you could be working on two or more projects at the same time - waiting on user acceptance testing - if one passes then you want to deploy that to live but not the  others.

The more I think about it the more I believe that my method of working is the only one that works for all possibilities - or so I believe - if anyone has a better method please tell

Peter

Hi John
Well hidden indeed - you would only find it by reading every line of the docs for each release

Peter

Just had to do this at a client 
And missed out another thing that I have to do....

This is a ZEN app that has custom components sub classed from ZEN - these create css and js files

But only in the master namespace/csp application

These files need to be copied to the other namespace/csp applications

peter

Hi Robert and all

You can achieve the separation quite easily with routine and class package mapping.

I have a client that has overseas affiliates they all share the same code/class base but have their own namespace with routines and packages mapped to the master namespace.

Works just fine

The only issue is that developing the code is more complex as the different affiliates have started to need different functionality starting from the same base screen

Peter

Hi All

The way I work is:- Personal Development Machines - Deploy to Test Server for User Acceptance Testing - Deploy to Live

The version control system that I use is TrakWarePro from Globalware - sadly no longer in existence  - but it works for us.  Not only to maintain versions but to ship releases between the three environments.

When deploying the classes need to be compiled (obviously) but I don't trust ISC compiling *all* the required classes and SQL statements etc.  Neither does $System.OBJ.CompileAll() work 100% in resolving the dependencies in the correct order.

Also a release will need to set SQL access on tables for any new data classes.

So I have developed a do ##class(setup.rCompileAll).doit() method that does all the necessary - in the correct order, set the SQL Access etc.

Usually a deployment will require changing data/updating indices/adding pages to the access database etc etc - so there is usually a setup class that contains the code to do this.

So I have

• a Studio project "pfcXXX"
• a version control project "pfcXXX"
• a setup class "setup,rPFCxxx.cls"

And all this works 99.9% over 10 plus years - I can't actually remember wen it went wrong but nothing in this world is 100% 

The downtime can be as little as 5 minutes for a simple release or up to 1 hour or so if the data changes are complex.

The only downside is system is unavailable to the user whilst this process is happening - I know about the technique of using mirroring and updating one mirror and then swapping - but this is overkill for my users.

Peter