Question
· Sep 14, 2017

Conflict Resolution Wizard

Hi

When trying to sync a class to the server where the server class has been updated by another user, I, as expected, get the Conflict Resolution Wizard.

I can then use the wizard to copy code from the server side to my local copy using the arrows also as expected.

But when I have integrated the remote code into what I think is my local copy how do I save it so that it gets integrated into my local copy and synchronised to the server.

I find if I click the 'Save Local Copy' button it ignores the changes I have made in the wizard and simply overwrites the remote class with whatever I had originally in my local copy

Discussion (9)4
Log in or sign up to continue

We are at the start of looking into using Atelier.

Our intention is to use BitBucket as source control so we will use the eGit plugin. The problems we have are we already have 3 environments (DEV, TEST and PROD) which contain code which will need uploading into three repositories or branches (not decided yet). But then we need the ability to move code between these locations which is what prompted my question. Since then I think I have found a different way of managing the conflicts.

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!

Following up one of Ben's points, if you're using a shared DEV namespace you can use a server-side source code management tool such as our Deltanji. This also gives you the option of using Atelier and Studio side-by-side, which is handy if you have a team of developers who may need to migrate to Atelier at different speeds, or if you deal with code components that Atelier doesn't yet handle satisfactorily. Also, Deltanji handles the migration of code from one environment to another (e.g. DEV -> TEST -> PROD). Using a client-side source control provider such as Git you'll need to put some other tooling in place to handle that.

Hi John

We havent spoke for a long time.

I assume Deltanji works in a similar manner as VCm, if so, I am aware of the advantages of that approach. We are at this moment still looking into Atelier as to whether we embrace it completely.

Code migration is something we are still thinking about. As you know we don't do full code migration between our environments we use small feature packages the approach of CR's in VCm is a very useful way of managing the release.

Hi Ben

Base lining the code as you suggest, is pretty much as we will end up doing. Its what we have done previously.

The  'server DEV' v 'private DEV' instances. Unfortunately we cannot have working DEV instances privately. We work on a very large integration implementation that has many external servers/services 'plugged in' to provide messaging etc, which unfortunately cannot be replicated. One approach we will try is using private DEV instances for small feature updates and using hand coded messaging for prototyping, but then integrating into the main DEV codebase for further testing.

One reason for my question is that we have a team of developers working on various parts of a namespace at any one time which obviously causes issues if we are working on the same piece of code (its rare but happens). I was wondering how people got around the paradigm of Atelier working against a single namespace and trying to reconcile that against Git with multiple developers working on the same piece of code. Without file locking I can see it creating more merge issues than the traditional 'private instance' of development.

Ian - I completely understand why moving to Private Dev is challenging.  It is very much the nature of applications built on top of InterSystems technology, and it is certainly a challenge.  

You are absolutely correct in your thinking that you will see a lot of issues in trying to use Client-Side source hooks (especially for a distributed source control system like Git) against a Shared Dev instance.  I actually presented at Global Summit last week about the interplay between Client vs Serverside hooks and Private vs Shared Dev instances, and I recommended that people avoid the Client-Side / Shared Dev combination.  I would recommend that you download the slides and watch the recording of my session - you will probably find it to be very helpful:

Global Summit 2017: Shared Development for the 21st Century

As you are tied to Shared Dev workflow, I would strongly suggest that you consider using Server-side hooks to enable your dev workflow, and that you use a centralized Version Control System (VCS) like Perforce, Deltanji or Subversion rather than a distributed VCS like Git.  Serverside hooks will enforce the behavior of both Studio and Atelier, so you can still move to Atelier and still use this (just make sure that you are on 2017.2.0, 2017.1.2 or 2016.2.3 as those are the first versions that contain a fix to a hole that was recently found in serverside protections with Atelier).  

In terms of your code promotion question, please keep in mind that Atelier is a development tool and not a deployment tool.  As others have said, TEST and PROD should never have code pushed to it from Atelier but rather the code needs to come directly from your VCS.  I run internal app dev at InterSystems and our process looks like this:

  • Shared BASE, TEST and LIVE environments
  • Private BASEs for some apps
  • BASE, TEST and LIVE branches
  • VCS is Perforce
  • Serverside hooks on Shared BASE control concurrency and locking of items as they are being edited on Shared BASE
  • All check-ins include a logic identifier for the project (a Job in Perforce) 
  • When project is ready to move from BASE to TEST, we have a script that integrates all changelists with that Job from the BASE branch to the TEST branch
  • Changed items are pulled from TEST branch into TEST environment and compiled
  • Same process for moving things from TEST to LIVE

This process works very well for us and scales well on a variety of sized development teams (larger teams use more private BASE environments to prevent check-out collisions on Shared-BASE).  We've been working in this mode for about 7 years and it's really stabilized our environments and branches (compared to how things were before) and we're well positioned to move forward with Atelier in use side by side with Studio.

Hope this helps.  Please watch my Global Summit session and let me know if you have any questions (I plan to write a new article based on my session so feel free to jump in to the discussion there).