Updated the agenda for the meetup - the new session by @Sergei Shutov has been introduced: 

Automatically configure a customized development environment. 

The session covers the approach and demo of creating a private development environment from source control, and how changes can be automatically pushed downstream to build and test environments. Show the use of open source Git hooks, %Installer, and Atelier, with Jenkins and automated Unit Tests.

Eduard, do you think it makes sense to DELETE everything in a namespace and then import code from checkout?

Consider DeveloperA deleted ClassB from repo and from his local NamespaceA

DeveloperB checkout repo and with only classA but still has ClassB in his local NamespaceB. What will delete ClassB in DeveloperB's working system?

The only "automatic" solution I see here is to check out and import classes into clear or new Namespace.

Or never delete classes, only "deprecate" it

Hi, Alessandro!

Thank you for the useful article!

Having Primary and Analytics servers is very important, the main reason being to avoid performance problems on either server. Please check the documentation about Recommended Architecture.

What is the type of mirroring is recommended? Should it be synchronous mirror or async, or disaster recovery?

Wow. That's interesting. I'm curious what will happen if a class was created in Caché and then modified in IRIS (e.g. with new property) - would it be another global for a new property? Could you check that?

I think if you created class first in Caché 2017.2 and preserve the storage definition within a class in version control you should be good with IRIS - I mean IRIS shouldn't change the storage of your 2017.2 class.

Hi, Peter!

I would warn you of NOT including storage information in Git (or any other CVS).  It is the must to keep class storage definition within source control.

Consider you have a system in production where you have class A with properties P1 and P2 with data.

And you developed a new version of a product with the optimization when you don't need P1 anymore and delete it. And you added a new feature which needs to add property P3

 You deploy new class  A with P2 and P3 properties on a production system. Storage would be generated upon class definition and you will get the following:

All reads from P2 would deal with former P1 data.

All reads from P3 would read former P2 data (yes, you will get P3 initialized by former unexpected P2 data).

So you'll get some unexpected behavior and bugs with this.

Solution:

keep the storage definition within a class and in Git.

Maybe delete a property is a bad practice but sometimes we are doing that.

HTH