Question
· Feb 4, 2021

Development and production servers with GIT as version control

Hi,

So I am a front end developer working with REST API with Cache database on the BE. The BE guys are currently using Cache through a Windows virtual machine and they claim it is not possible to have a development server to work with. All the work they are doing is directly on the production server and changes are immediate and I think this is a bad idea going forward and we most definitely need a development server that has access to the same code base and different version (through git) to be able to do development. We also do all the testing on this production server with test accounts, but we cannot do automated testing with this setup.

Is it possible with Cache 2017.1 to have GIT as source control and the scenario I described above with development server up and running to use the same code base sourced through git ?

Product version: Caché 2017.1
$ZV: field not included in the demo video, so I don't know what this is
Discussion (11)2
Log in or sign up to continue

Thanks @Dmitry Maslennikov 

I am not actually working on this BE with Cache, I am developing the FE for an app that uses Cache on the BE and they keep telling me it's not possible to have a development server because then they would need to have a separate server with a different copy of the cache codebase because for some reason it's baked into the database and they would then need to update both servers separately.

They don't use source control at all, they just write everything on the production server and it's live right away

DO you know anything about this kind of issue ?

Yeah, It's a bit tricky. All the code in Caché really stored directly in the database. But with VSCode, code can be stored locally as files, for easy access and the ability to use source control such as git. After any save of the file related to Caché, e.g. Classes or routines, it will be sent to the server and compiled there.

Having a separate development server, and a production server are for sure is best practice, for sure. With no permission to edit code directly on production. And with having DevOps, will be possible to build a production version and easily deploy it, by some actions or events.

If the BE guys are currently all working on the same copy of the codebase in a shared namespace on the production server, I think it will be an easier transition if they adopt server-centric source control such as Deltanji from my employer George James Software. They could start off by putting the production namespace under source control, then evolve to an architecture where development happens in a different shared namespace (could be on the same server, or on a different server), or separate namespaces for each developer, feeding an integration namespace where testing happens. Deltanji is very flexible and configurable, plus the configuration can be changed as the team's needs change. It integrates with Studio and VS Code editing tools.

Evaluation copies of Deltanji are available, and we're happy to set up PoCs for development organizations who are interested in trying it out for themselves. We can put people in touch with existing users, and some of those users might post a response on this thread too.

John Murray
Senior Product Engineer
George James Software
https://georgejames.com

Hi Sorin!

It's definitely possible to have a development server and deploy code to a production server.

Caché code could be maintained with Git of course.

For automation they are very welcome to use Github Actions, Circle CI, etc.

There is a question how to import codebase to a production server or any other deployment server - the basic approaches are:

Import using the repo folder and Installer.cls

Use ZPM Package manager.

Use InterSystems Docker images  - this is a more IRIS way then Caché. 

Developing in the production environment is "high-risk extra class".
This doesn't exclude to do development on the production SERVER (e.g by lack of HW)
The most simple option is to have 3 namespaces in parallel. PRODUCTION (aka WORK), TEST, DEVELOPMENT.
A better variant is to have a 2nd instance on the same SERVER machine for  TEST & DEVELOPMENT.
Git doesn't care which Instance you use.
ZMP is not availaible in Caché.
Docker is theoretically possible but quite an effort as you need to build your own image especially for a WIN environment and get the appropriate license for it.