New post
AllAccepted answers
Ben Spead · Sep 15, 2017

Ian,

If I were you, I would approach this as follows:

1) Baseline the code on all three of your servers using the "Caché UDL" project on GitHub

2) Use the PROD baseline to make your PROD branch/repot

3) Fork/Branch to make your TEST repo, and then check in your changes from TEST baseline on top of the changes integrated there from PROD

4) Do the same thing to make DEV - Fork/Branch from TEST and then check in your DEV Baseline on top of it

Now you should be positioned to integrate changes from DEV to TEST and deploy out of source control, and then the same from TEST to PROD.  This allows you to handle your merges within source control and not rely on merging from your IDE as part of a code push.

Side note - I expect you'll run into some frustrations trying to use client-side hooks against a shared DEV instance if you are not careful (I just did a presentation at Global Summit this past week which highlighted the challenges of that approach).  I would recommend that you move towards Private DEV instances as soon as you can, or if you intend to stay using a Shared DEV, then you might want to consider Server-side hooks instead (that being said - Git doesn't work very well in a shared dev type environment with serverside hooks, so this again points to the importance of moving towards private DEV instances as soon as you are able).  There will be several recordings from Global Summit which should be interesting to you on this topic - we'll be posting articles in the near future with the content so stay tuned!

Ben Spead · Aug 23, 2017

There is a huge benefit from two perspectives:

- If you need to refresh data in your Dev or Test environment, you can just grab the globals DB from Live and drop it in and not worry about overwriting any code in Dev or Test

- If you choose to deploy your code via a DB drop, you can drop in a new DB to replace the existing routines DB

NOTE - for either of these to work, you may need to map configuration into the routines DB (so you don't bring back Live config into Dev for instance)

HTH!

Ben

Ben Spead · Aug 8, 2017

FYI ... we will have several sessions covering this topic at the Global Summit - attend if you can, otherwise check out the material afterwards!

For internal application development within InterSystems we use a variety of approaches, but the most common is as follows:

1) We use an internally developed issue tracking system, but we plan to eventually migrate to JIRA

2) We use Perforce for all of our source control 

3) We have BASE, TEST and LIVE environments for every application, typically BASE and TEST being cloned from VM snapshots of LIVE.  In addition to the Shared BASE VM, for those applications which are undergoing the highest rate of change, developers will create a local copy of the application to do their development work.  Some apps have all changes being developed on Shared BASE and the changes are progressed (via our Change Control tool) to TEST and the LIVE.  For applications where developers use Private BASEs, they commit there and then push the changes to Shared BASE and then to TEST and LIVE.

Feel free to ask questions (here or at Global Summit)!

Thanks for asking.