This is definitely possible, although it will be very painful :)  You can use Studio to edit any sort of flat files on the OS, and Studio has been used for years to edit .js and .css files.  You can use Studio to edit the source files for your React or Angular app, but you will then need to use the CLI in order to build your app for testing (you could also roll your own server side source control hooks to do this).  So if your organization is currently locked into Studio, this can be done but you'll need to do extra work to make it work.

If you have the flexibility, I would strongly recommend that you leverage VSCode rather than Studio for this.

@Rich Taylor - John is correct, server-side source control models are fully supported and that is the dominant model for many (including internal apps at ISC, and our implementations in the field).  I did a presentation at Virtual Summit on how to choose between Private / Shared Dev servers and Client-side vs Server-side source control and what the IDE options are for each.  Tim Leavitt also did a session on the topic of server-side source control with VSCode.  Here are the links:

https://learning.intersystems.com/course/view.php?id=1638

https://learning.intersystems.com/course/view.php?id=1615

My team has been very active in the VS Code plug-in testing and development to ensure that it will be fully functional for our serverside source control based workflows.

Sorry @Jeffrey England - I only just saw this now (feel free to use an @ mention in the future).

This control doesn't currently include any sort of dropdown.  It was based on the System lookup in the old UI where people could just drop in their SysCode to drive navigation.  Adding a dropdown of some sort is on the roadmap, but it's not trivial as some people have access to hundreds of Systems (so it's not a simple dropdown - it will eventually be a combination typeahead dropdown which pulls from all Orgs a user has access to).  

We will be moving live an update to this component soon which makes it more clear that SystemCode is optional (but it will still be a text field).

Hope that helps explain things!

Ben

Phuc,

Assuming the SQL is being run synchronously from within the CSP page, then the page will not be able to send it's response to the client while it waits for the SQL to complete.  Are you saying that the average response time of the query is 1.4 minutes?  If so then I think you need to see if you can speed up your query, call for the data asynchronously, or change your CSPGateway configuration so it has a longer timeout.

I agree with both Tim and Evgeny.  In addition, I will add that we also store our unit tests in a different location, which has a top level of /internal for all of our in-house applications.  We store unit tests and test data in /internal so our integration scripts can explicitly ignore changes in those branches when we're porting things to our LIVE branch.  This ensures that no testing code or testing data ever make it into production.  

@Perla Escarcega  - that is one of the ways to do a Refresh, yes.  You need to first populate all files in your Source Workspace, and then the Refresh will walk the directory contents and load everything in.

More details can be found on slides 43-45 of ICC520:

ftp://ftp.intersystems.com/isc/customers/ccrtraining/ICC520(Presentation)%20CCR%20Tier%201%20-%20Baselining%20Source%20Code.pdf
 

@Perla Escarcega  - taking a closer look at this, I think we had an issue with a historical file clean-up routine which was a little too overeager to reclaim space.  All of your source is safe and available but you may need to create a fresh ItemSet to push this source.  Note - you should always be making fresh ItemSets anyway because the head revision may be newer than what is in your historical ItemSet, and you don't want to get an older revision of something which breaks when interacting with a newer revision of other items.  So simply create a new ItemSet for BASE and deploy it and you should be all set.

P.S.  This does raise the question of why you are initializing a new Secondary BASE environment from old ItemSets as opposed to just grabbing the head revision of the BASE source and running Refresh to pull it all into the Namespace?  I am afraid your approach may be significantly more risky than the recommended approach.  

@Perla Escarcega  - the fact that it is already in LIVE should not have any bearing here.  I am guessing that the newly created Namespace is part of a newly created instance?  It looks like you may have an older version of the CCR Client Tools with a bug in it.  Could you provide the results of "Do Version^%buildccr" so we can see what versions of the tools you are running?

I hope that someone else can chime in and confirm, but my understanding is that we don't release Caché on containers, only InterSystems IRIS containers (I just looked in the Distributions section of the WRC to confirm).  However, you should be able to get a InterSystems IRIS container to play with so this shouldn't be a blocker for you - just grab an InterSystems IRIS container (available via the WRC Distributions page, or Docker Hub) and use that to try the demo.

In terms of Caché on containers, I know that there are people in the community who have 'rolled their own', and you can find details on threads here, but I don't think you want to go in that direction if you're new with containers.  

HTH - good luck!

Ben