Code migration using VSCode

Question

Question

Scott Roth · Dec 9, 2020

I am fairly new to using VSCode. I have used VSCode to create some files on our Test Server, now I need to move them to Production.

Looking through the VSCode extension documentation, maybe I missed it but how to I migrate code from one workspace to another. In Studio I was use to exporting the code into an XML and just being able to import it on the Production server version of Studio.

Thanks

Scott

Product version: Caché 2018.1

$ZV: Cache for UNIX (IBM AIX for System Power System-64) 2018.1.3 (Build 414U) Mon Oct 28 2019 11:24:02 EDT

Discussion (9)4

Log in or sign up to continue

Dmitry Maslennikov · Dec 9, 2020

First of all, it's not a common case for any code editor, and for sure VSCode is not an exception. What are you talking about is kind of deployment process. And have to be solved in that manner. You have to produce some kind of version of your application and install it. It's how it's supposed to be.

At the moment with VSCode, you can export any source code from the server, to get all the classes locally. And import those files as a folder. But it may not work as you would expect, and may cause some compiling issues. This case will not be changed in the future, as completely make no sense to have in the Editor.

0 0

score 0 · Answer 1 · 2020-12-09T16:34:04-05:00

Scott Roth · Dec 9, 2020

Ok thanks.

0 0

score 0 · Answer 2 · 2020-12-10T07:10:20-05:00

Eduard Lebedyuk · Dec 10, 2020

Use CI/CD for that. Here's an example.

0 0

score 1 · Answer 3 · 2020-12-11T05:31:29-05:00

That's one of the benefits of using George James Software's Deltanji for your source control. As well as code versioning you get highly configurable deployment facilities. Here's a recording of me using Deltanji integrated with VS Code to transfer to my test namespace the two classes I've been working on as part of a task.

score 0 · Answer 4 · 2020-12-11T08:30:17-05:00

Scott,

One thing to keep in mind is that all code that you create or edit in VSCode is stored locally on your development machine as well as on the server (when saved and compiled). There is no need to export the code as it is already "exported". Just not packaged up into a single file.

To the question about how to get this project into Production. The "proper" way is to have source control enabled with a proper development work flow (DevOps / Continuous Integration) such that you would just promote the work to the production stage. The implementation of your workflow should take care of moving the artifacts of your development into production.

Given the way you present the question I am going to assume that you don't have source control or a development workflow in place. So to take all the code you have carefully developed tested in the project and move it to production you can take two approaches. Keep in mind that this will only get the code that you have changed and not other artifacts like configuration globals or settings.

(safest, and I use the word safe very loosely here. Refer back to my "proper" comment above) would be to take the folder/directory where your project currently lives and copy it to a new location. Edit the connection settings then "import and compile" the code. Do this by right clicking on the folder where all your code lives ('src'). Select "import and compile"
Same as #1 except you edit the connection settings in the same folder that you did development. THIS IS DANGEROUS if you forget and start doing more work.

A PROPER SOURCE CONTROL AND WORKFLOW process is really a better way to go. It will take a little effort to configure for your desired flow. Again I am making an assumption that you are not using Docker Containers so automating the process will be a little more involved. Tools like Chef and Puppet will help. You will need to research what would work best for you. As I said this will take some effort to get setup. In the end it will help you in time and consistency of process.

Take a look at this article series on the community which may help:

https://community.intersystems.com/post/continuous-delivery-your-intersy...

score 0 · Answer 5 · 2020-12-11T08:51:44-05:00

@Rich Taylor wrote:

One thing to keep in mind is that all code that you create or edit in VSCode is stored locally on your development machine

That is not necessarily true. The model of working in which code is stored and source-controlled on an InterSystems server is perfectly valid, fully supported, and suits some teams and organizations better than the model that uses client-side source files and file-based source control tools such as Git.

See here for how this is done when using the InterSystems ObjectScript extension in VS Code.

IIRC the internal applications team at InterSystems works this way.

Our Serenji extension also uses the server-side model.

score 0 · Answer 6 · 2020-12-11T10:27:26-05:00

@John Murray
Interesting. I had not seen this update as I am fairly sure the earlier versions didn't allow that functionality. That is an interesting option. Though, I think many will not make the effort to configure this way without a clear need to do so. I will definitely try playing around with it.

score 0 · Answer 7 · 2020-12-11T10:36:15-05:00

@Rich Taylor
Working direct on the server using the isfs FileSystemProvider first arrived in 0.7.12 on Aug 29, 2019.

score 0 · Answer 8 · 2020-12-11T10:42:21-05:00

@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.