You would also need to be careful of the following:

•  integration endpoints (e.g. web service calls (especially those inserting data), POP3 mailbox retrieval, FTP fetches, etc)
•  email generation code in your app
•  task schedule
•  NFS mount points

You must be very careful that your non-production instances do not behave as production post-cloning (e.g. you would never want a test system generating emails to non-developers).  We have all of our code-base instrumented so that with a single configuration global we can control production vs non-production behavior (including where to go for web service calls, etc).  This allows us to have identical code across all environments, but only Prod will send email, fetch actual user files, insert real data into other systems, etc.  We then have our application-specific configuration globals mapped to their own Config DB, which means:

• when the Data DB is restored from LIVE it doesn't bring configuration data with it (i.e. we need to avoid a Test system suddenly thinking it is Prod because the global indicating Dev|Test|Prod is restored from Prod)
• when we run a test build for CI on our Build servers (also cloned from Prod) we can start with an empty Code DB (and pre-populated Data and Config DBs) and everything "just works" :)

Glad to hear that you are already virtualized - that can really save you a lot of setup and config time.  Let me know if you have any additional questions :)

(P.S. Chris, welcome to the world of Caché and DeepSee!!  I hope you find the Community to be helpful.

note - if you are happy with this answer, please mark the Answer as Accepted so this thread falls off of the Unanswered Questions list)

For my team we always deploy on VMs, which makes it trivial to clone the VM to create our Dev and Test instances (this helps ensure complete equivalent for all Caché settings, OS patch level, OS settings, etc).  When we moved to this approach it really helped to improve our testing stability and predictability (we have our Code and Data separated into different DB, so the Code DB is updated from source control and our Data DB can be updated weekly with restoring the backup of the Prod Data DB.

If you are currently deployed on bare iron this won't be an option for you.  But if you are virtualized for production (or can move to it in the future) you may find that it saves a lot of hassle for your Dev and Test instances.

Alexey,

The post you referred to was with respect to license key changes - I didn't see any guarantees that a previous non-Ubuntu installs would be upgradable (in fact I would be surprised if they were).

I suggest you contact the WRC for final confirmation, but I expect you'll need to start with a fresh instance and move over your code, config and data.

Ben

You are looking at the download site for free copies of the software for evaluation.

Supported customers can download the Ubuntu kits from the Distributions page in the WRC:

https://wrc.intersystems.com/wrc/coDistribution.csp

Contact your account manager if you don't have access and think you should.

Hats off to you Sean!  You did a great job pulling all of this together!

Not sure if it is worth listing or not, but here is an *ancient* open source app written in Caché which may still be interesting to some people:

http://onforme.sourceforge.net/

https://sourceforge.net/projects/onforme/ 

(not guarantees that it will work out of the box with current versions of Caché ;) )

What is your browser and version?  Is it by any chance Firefox 57.0?

EDIT:  Nevermind - I see that you said Studio ate all of the licenses, so unless you are launching pages in a web browser from Studio my hunch probably isn't correct

Glad to hear it is working!

Could you please mark the Answer below as accepted so that people know that it worked?

You can run this from Caché Terminal, or put it in a routine or class and run it:

USER>Set httprequest=##class(%Net.HttpRequest).%New()
 
USER>Set httprequest.Server="www.intersystems.com"
 
USER>Do httprequest.Get("/")
 
USER>Do httprequest.HttpResponse.OutputToDevice()
HTTP/1.1 301 Moved Permanently
CONNECTION: keep-alive
CONTENT-LENGTH: 178
CONTENT-TYPE: text/html
DATE: Thu, 12 Oct 2017 14:21:23 GMT
LOCATION: https://www.intersystems.com/
SERVER: nginx
X-TYPE: default
 
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

Great tip - thanks John!

Ah .... by default, you might find that the REST service used by Atelier is set to Unauthenticated:

/api/atelier 

We have found that we need to make sure that this is configured for "Password Authentication" in order for our server-side source control hooks to operate properly.