Development vs. Deployment

, , ,
1

When code can be compiled and executed locally, I would expect an application to follow this model:

Local Development <--> Source Control --> Remote Target

Applying this model to our environment, in which we are working with Natural for the Mainframe, is proving tricky. Right now we are trying something like this:

Eclipse (local) <--  Mainframe (remote)
Eclipse (local) <--> Subversion (source control)
Eclipse (local)  --> Mainframe (remote)

This works, but it leaves open the possibility that the source code put on the Mainframe does not match the source stored in Subversion. I’m comfortable with this model for libraries under active development, but not for stable libraries. I’d like to ensure that our stable libraries do match our Subversion stores.

How does Software AG recommend this be configured? I read the help document on Architecture, but that didn’t answer this question for me.

Thanks.

2

I don’t have a deep knowledge about Natural on eclipse. But this week, we have started to discuss about Natural for eclipse at our company. Our initial setup is as yours. And we came to the same question. BTW: The code cannot be compiled/executed locally in our case. Everything (NATURAL + Database) runs on Solaris.

From my point of view, the problem is a philosophical one: CVS, Subverion and Eclipe are built for “distributed development”. Natural isn’t build for that. Remember the meaning of the acronym “SPoD”. But anyway…

If I unterstand you correctly, your solution would be:

  1. The Natural-Code is compiled and exectued locally - maybe in connection to an ADABAS-Database via Entire Net-Work. Maybe you have to fight against system incompatibilities (Mainframe ↔ PC in your case / Solaris ↔ Windows in our case).
  2. Subversion is responsible for the sources and generated modules on the Natural target. Only if a source is checked in, the corresponding natural objects should be written onto the Natural target. I guess this is not possible at the moment.

I think about another solution:

  1. No local compilation/execution
  2. During checkout, the corresponding natural-modules on the Natural target are copied to a user-specific working library (also on the Natural target). The original library is steplib. An “upload and compile” only changes the working library. During checkin, the modules are moved back to the original library.

I don’t know, if my idea is good or not. What do you think?