Per your second question, best practice is generally to use System Defaults which are set in your Namespace and store the production settings (rather than storing them in the Production class).  This allows you to prevent having to have differences in the Production class between branches.  

Steve - #2 is helpful if you want to leverage existing structures for authentication, auditing, transport or other functions that rely on CSP sessions .  This can be used as part of a strategy of incrementally moving an application from a CSP-based architecture to Angular. 

@Peter Cooper 

Thanks again for sharing the start of your journey with the Community.  I am curious if you are planning to provide another Update Article?  I would love to hear about how your journey has progressed over the past year and what you have learned along the way which could help others!

Cheers,

Ben

Exactly!  We are actively using it internally within InterSystems - both in internal application development, and in HealthShare product development.  As discussed in the video we have found incredible value in this tool for decreasing technical debt (and making sure new changes don't add to it).  We thought customers might find the value in it as well.  

@Mike.Davidovich 

You are most welcome.  In terms of why TestCoverage was released on OpenExchange, it is something we have been exploring internally last year and wanted to share with the Community in time for Global Summit 2018.  In terms of whether or not it will actually make it into product, I can't speak to that but perhaps the author @Timothy Leavitt  can comment on that (I believe there were at least exploratory discussions with Product Management on this topic).

The first half of that should be helpful.  Code coverage may be helpful too if they are able to move into a CI type BUILD infrastructure (I don't know how well Test Coverage would work in a more dynamic Dev environment as longitudinal history might be harder to maintain ... haven't really thought about that too much before...)

Sorry -  I forgot that you first need to specify the source control class in the Management Portal.  Put "Source Control" in the Search box on the SMP homepage, and then go to that page (e.g. http://localhost:57772/csp/sys/mgr/%25CSP.UI.Portal.SourceControl.zen).  Select the Namespace in the left column and then "%Studio.SourceControl.ISC".  Save the changes and try the BaselineExport() again.  When you are done with the export, change the Source Control back to "None"

As a general tip, if you do enable and enforce source control, then you wouldn't need to be querying your class definitions to find variations between environments - you could see all of that (and so much more!) in your source control system ;)

I understand ... so you want to only export specific things which it has found to have differences in the code.  That makes sense since you are trying to use it at the end of a piece of code already in place.  I am afraid I don't know how to do that, but if you contact Support they may be able to suggest a trick or two.

Is there a reason that the use of a Virtual Namespace is a requirement? If not, you can use ##class(%Studio.SourceControl.ISC).BaselineExport() to export the entire contents of the Namespace to disk for file-based diffing (this is how I normally do it)

Welcome to the the InterSystems Developer Community!!

1) ObjectScript is a (very, very large) superset of the M language (previously known as MUMPS)

2) InterSystems IRIS uses much of the core technology that was in Caché, but it is a break from the past in many ways and allows next-gen development tools, architectures, etc.  InterSystems IRIS is an upgrade path which current Caché based applications should seriously consider.  Zen is a legacy web development technology which runs on top of Caché (it ships with Caché and InterSystems IRIS)

3) The answer to this depends on whether you are taking straight globals, or persistent objects.  Any data persisted via InterSystems Object or Relational structures can automatically be accessed via SQL.  If you are just writing straight globals (e.g. set ^Patient(123)=foobar) then you can't query unless you set up an SQLStorage mapping to your globals

4) You can map your existing global structures to object definitions for OO/SQL access using SQLStorage (https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...).  It looks like there isn't a lot in the docs on that so you should contact Support for more details on how to set it up to match your existing data to definitions which you can hit with traditional SQL.

Hope that helps!

Excellent article Michelle!  Very well done :)

I absolutely concur that if a shared dev instance is going to be used along with client-side hooks then locking is a *must*!  However, some may find that exclusive ownership on a single Shared dev instance is too restrictive, but find themselves still needing a Shared dev instance in the mix for certain reasons.   

An alternative would be a Mixed mode of working with a Shared Dev and one or more Private Dev environment.  We have found that this mode works really well for us in the case for large teams on active projects - locking across the board we've found to be too restrictive in how it blocks work.  We have found this on a couple of our most active applications where we need shared development instance for a number of reasons.  In order to make this work, you will need to move to using  Server-Side Source Control hooks on the Shared dev instance, and then developers that don't require work on the shared dev instance can have a private instance which uses either Server-Side or Client-Side source control hooks (in our case we use server-side in Private dev instances to make it easier to support).   This will work because the Server-Side Hooks on Shared should manage concurrency of any developers connected to that instance (they can't check out a file someone is already working on), while not locking the file in source control which would prevent other developers from touching it on their Private Dev instances.  

Just throwing this out there as another option for those who find that they are tripping over exclusive locking, and are not comfortable running with unlocked files on the Shared Dev instance.

Also, a big thumbs up for including the suggestions of Jenkins - we have started using it this year to automate build/unit/code coverage testing on every check-in and are seeing some great results!

It's deprecated but still available.  Swapping it out for $zf(-100) for %Studio.SourceControl.ISC is on the TODO list...