New post
Question
· Apr 28, 2016

Git and Atelier

#Development Environment #Git #HealthShare

Hi,

I'm in the process of trying to convert my team to a Git-based workflow for source code version management (we use Ensemble and HealthShare, but build a lot of customizations on top). We are having a hard time working with Atelier in this regard for a few reasons:

  • Atelier always wants to sync the local files with the Cache server files, so switching between git branches causes all sorts of mayhem with the synchronization. Creating new files locally leads to a similar problem. There doesn't seem to be a way to disable syncing or to manage an Atelier project without maintaining a connection to a Cache server.
  • There's no way to sync non-Cache files to the connected Cache server from the local file tree, meaning that we have to leave Atelier to deploy javascript changes. This makes for a slow and awkward development feedback cycle.
  • Ideally, a single Atelier project could also support connections to multiple Cache servers so that it could be used as a deployment tool as well. This is sort of possible now by manually changing the connection every time I want to deploy to a different server, but combined with the invasive automatic syncing this can easily lead to mistakes (especially since each Cache Namespace seems to require being its own Atelier project with its own connection settings).
  • Atelier reports more errors in COS code than Studio does, which causes a lot of red X's to appear all over our project. In particular, the omission of function parameters is a big contributor.

Has anyone found an effective multi-developer workflow using Git and Atelier? Any lessons learned that you can share? Am I just missing some common Eclipse best practices (it has been awhile since I've worked with Eclipse)?

Any advice is much appreciated!

Discussion (11)1
Log in or sign up to continue
Patrick Newton · Apr 29, 2016

1) The git issue you raise is VERY interesting, the problem stems from git swapping one branches code out from underneath you and replacing it in the same structure. This is clearly different from many other source control systems where branches are placed in distinct trees in the file system (this is what we are used to at Intersystems, as we use Perforce). Addressing this issue will require some careful thought and I think working in a disconnected mode ( something which we are working on ) will only partially solve the issue.  So the answer here is we hear you loud and clear, we are working on disconnected mode but need a little time to think about all the ramifications.

2) You will be able to SYNC no Cache files to the server when CSP support is completed. We are still working on this aspect.

3) We were not planning on Atelier being a deployment tool, I know Bill McCormick has strong views on this subject and I will let him answer this particular issue

4) Again what you see in Atelier is a work in progress, syntax coloring is a very high priority for us but as you can appreciate its a significant task. We wanted to get Atelier into users hands so we could get valuable feedback such as yours so we couldn't wait for a perfect syntax coloring experience. We promise to deliver that. It will just take some time

5 0
Bill McCormick · May 2, 2016

In general I am of the opinion people should use the right tools for the right job. There are IDEs that are for producing code. There are source control systems for maintaining code and its history. There are tools for doing deployment. They are not all the same tool. I just spent a few days visiting a site that has the ability to do push button deployments of complete installs or patches to public or private clouds. That is how people should be looking at this issue. Its the realm of DevOps, and Cloud and enterprise management systems. Not the IDE itself. We can do this with Atelier. I can pull a project from source into an Atelier project and then push / sync it to a given Cache instance. But this is not the optimal way to distribute code.

I encourage you to take a look at a tool like Chef as one example of a more modern way of deploying code. There are many many many more options out there but it is not my expectation that Atelier is ever going to be my preferred method for distributing code from source to production.

4 0
Travis Thurber · May 8, 2016

Actually, is anyone willing to share examples of their automated deployment strategies (i.e. chef cookbooks)? Being relatively new to working with Cache, it's not immediately obvious to me how I could write a script to take my plain text source code, send it to a Cache instance, and compile it automatically. A quick search of the docbook for "deployment" revealed this COS code for compiling a class:

Do $System.OBJ.Compile("MyApp.MyClass")

But the new source code would have to be in the Cache database already. Are there any interfaces exposed in Cache for remotely transpiling plain text source code into the database? I assume the Atelier REST service is doing something like this.

0 0
John Murray · May 3, 2016

Travis, are you aware of our well-established native Caché/Ensemble/HealthShare source code management and deployment tool? Previously known as VC/m, it's now called Deltanji.

As well as dealing with code versioning Deltanji also handles deployment. It integrates with Atelier, Studio and Portal.

Some members of this Developer Community may be willing to share their experiences of using our tool.

Perhaps you have specific reasons for wanting to go with Git, but it might be worthwhile considering Deltanji as an alternative route.

John Murray
George James Software

1 0