New post
Discussion (3)0
Log in or sign up to continue
Eduard Lebedyuk · Aug 17, 2018

Generally speaking, inside Caché you must have two functions

InternalToExternal(name) As %String

ExternalToInternal(path) As %String

That translate Cache names (/app/index.csp) into filenames (i.e. C:\Temp\MyRepo\CSP\app\index.csp) and vice versa.

Your CI system should:

  1. Build git diff between target commit and environment current commit. Sample code.
  2. Separate diff into 2 parts: added/modified and deleted.
  3. Load added/modified files into Cache.
  4. Translate external names for deleted list into internal names.
  5. Delete items from deleted list.
  6. Set current environment commit equal to target commit

Here's a series of articles on building a CI/CD pipeline for InterSystems Cache.

1 0
Arcady Goldmint... · Aug 17, 2018

This is exactly what we do. We have an APP-CODE database, and the CI build process is basically:

  • pull the latest source from source control.
  • load the build script (which is an ObjectScript class that does the rest of the steps).
  • the build script then deletes the APP-CODE database and creates a fresh one.
  • populate the fresh APP-CODE database the source code checkout from the first step.
  • Run tests, collect results, etc
This way we can be sure that what is being tested in CI always matches what is in source control.
0 0
Evgeny Shvarov · Aug 17, 2018

Hi, Lassi!

Consider you have two databases on your production system:

AppData - with application data

AppCode - with the code for your solution.

AppData namespace maps classes needed for the application in AppCode.

You deploy your releases only in AppCode namespace. In this case, you either delete everything before deploying the latest release or delete and create a new AppCode database the with latest release.

And you shouldn't bother of deleted classes in the repo ;)

1 0