@Paul DeSantis - By default, all InterSystems Login users can only see the last released version of a product as well as any available preview releases.  Users that are Supported Customers (meaning they have been given access to our Support system as part of a Supported Organization) can access older builds, either through Evaluation or directly through the WRC Direct application.  Do you have a 2nd account which is tied to a Supported Org?  Or do you have a colleague who does?

@Alan Watts - there is no client-side Git plugin for Studio.  Studio works exclusively with server-side source-control hooks.  This is what the git-source-control package on OEX is ... it is server-side source control hooks to allow multiple developers to properly interact with a git repo from a single Namespace within InterSystems IRIS.  So once this is properly installed and configured for a given Namespace, once you connect via Studio you should see new top level Menu items in Studio and all changes will be governed by the source control hooks.  Nothing else is needed to be installed on the developers' Studio instances in terms of plug-ins, etc.

@Colin Brough - this was recently discussed on a thread internal to InterSystems, and I credit @Eduard Lebedyuk 
for the following options, which were suggested within the context of Enabled/Disabled Business Hosts on different environments using the same Production (some don't apply to your question about logging and testing, but I include them all for completeness):

1. Track a separate production class for each environment.
2. Use SDS to effectively disable Business Hosts (for example, by setting the Port property to an empty string).
3. Create a custom adapter/business host that has SDS configurable setting "RealEnable", which would be checked in OnInit or OnProcess input.
4. Use Interoperability Schedules, with Business Host always off/on.

I think (1) and (3) would be most likely to work for you here.

Also, it's not going to help you in the immediate term, but be aware that TestingEnabled (along with some other fields) is supported for SDS starting in InterSystems IRIS 2023.3 (I am very excited about that!!)

Sounds like you are using client-side source control in a shared development environment ... this is just a formula for frustration.  Either use private dev instances with client-side source control, or use server-side source control with a shared dev instance.  This was the theme of a presentation we did at G.S. a couple of times.  See https://community.intersystems.com/post/new-video-shared-development-21s...
NOTE - This was given a 2nd time where we used VSCode and not Atelier but I can't find that posting for some reason.   However the principles are identical whether you're using Atelier or VSCode ... they use the same APIs to manage source with the server.  

The issue is that you need the logic to run synchronously in process so that it can actually write out the JavaScript as part of the response to the web client. If you job off the logic it will run in a separate process and there is no way to return the JavaScript to the caller because this is done asynchronously and the response has already been sent by the time your job will finish in all likelihood. If you need something to run asynchronously then use the #call() command in your CSP page.

@Pietro Montorfano - VSCode use with CCR is definitely supported.  You just need to make sure that your workspace is properly defined with isfs, etc to get you access to the files on the server.  Since CCR uses server-side source control hooks, you can actually have people using Studio and VSCode concurrently against your BASE Environment.

We've tried to make it as easy as possible by allowing you to export the VSCode workspace definition directly from CCR (credit: @Timothy Leavitt ).  Go to your Environment Details page and use the "Export (VSCode)" button on the top of your Environment list:

Please try it and let us know if it works for you.  P.S. would you mind adding the #ccr tag to your question so others can easily find it?

@Abhishek Raj - start with reviewing the documentation for new features, and Upgrade Compatibility checklists:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...
This will be the most comprehensive collection of suggestions, things to know, and 'gotcha's' to be aware of.  

Beyond reading the docs and seeing what is applicable to your environment, do a practice upgrade of your application and TEST, TEST, TEST :)  

Lastly, make sure you review the supported platform list for 2018.1 and 2015.2:

2018.1: https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

2015.2: https://cedocs.intersystems.com/ens20152/csp/docbook/DocBook.UI.Page.cls...

Hope that helps!

@Alexey Maslov  - check out https://openexchange.intersystems.com/package/isc-codetidy .... this package includes automatic expansion of ObjectScript commands.  Even if you don't want to use the whole package, you can find the sample code to do expansion.

@Evan Gabhart  - can you please advise as to the specific class where the expansion code can be found?

@Ephraim Malane - without having the actual CCR IDs, most likely the case is that your CCR deployed through TEST added a file, and CCR will automatically detect if the CCR that added a file is not yet in the target environment and therefore will prevent other CCRs from 'leap-frogging' past it.  This is because if you leap past a CCR which originally adds a file, if you later need to back out the CCR it will result in a 'delete' of the file from all environments (because you're undoing an 'add').  

Probably the best bet for you is to reach out to Support so they can help you manually move the 'add' into the CCR that you want to move forward.  You will probably also need help cleaning up the CCR that you cancelled, as I am guessing that the backout failed due to edits already being promoted to TEST on top of the 'add' that you are trying to back out from there.

As we looked into things further on our side, it appears as though the UNIX 'hostname'.  We were able to resolve the issue in UNIX by doing the following to change the hostname to 'mynewhost':

log in as root
hostname mynewhost
echo mynewhost > /etc/hostname

The 2nd line will change the hostname in the current processes, and the 3rd will make sure that the change will persist during a reboot.  

Hope this is helpful to someone else.