New post
Question
· Mar 5, 2016

Development teams and namespaces

#Caché #Development Environment #Ensemble

If you've got more than one developer on a project, do you each work in your own namespace? Or do you all use a common namespace?

Through my work at George James Software I have encountered many different Caché and Ensemble development setups. At risk of over-generalizing, the older and more established users of InterSystems technologies seem more likely to have all their developers working in a common namespace, whereas the newer 'converts' tend to favour giving each developer their own namespace.

I think it'd be interesting to discuss the pros and cons of these options, and to consider hybrid or alternative arrangements.

Does it depend on whether you're working with Caché or Ensemble? Writing web apps or services? Coding something new or supporting/enhancing an existing product? Working with 20 classes or 20,000? Dealing with small quantities of data or enormous volumes? Using "waterfall", "agile", "pair programming", or XYZ as your methodology?

Please add your comments to this thread.

Discussion (7)1
Log in or sign up to continue
Herman Slagman · Mar 5, 2016

Considering myself among the 'the older and more established users of InterSystems technologies' ;-) we've always used the setup where each developer has his/hers own development machine. How the 'sandbox' namespace is called is not relevant. We use Git to tie the stuff together (more and more automated). It is allowed, or even encouraged, to use different versions of Caché or (in our case) Ensemble, which sometimes results in code that is not compatible with the current Production version, but we detect that in our QA phase and that might trigger discussions wether to upgrade Production if a used incompatible feature is of great value.

Having a separate development sandbox leaves room for experimenting which you wouldn't have if every developer is working in the same namespace, where in my opninion 'not to step on each others toes' would be much too constraining.

It will probable the same when Atelier takes off, some of us will be using that while others will stick to Studio or even brew their own in MS Code. 

4 0
Dmitry Maslennikov · Mar 5, 2016

In our company, all developers usess their own installation of Ensemble. We develop web-application, and most of our changes we do on server-side code, and support only one version of Caché. In a team with more then one developer, but on one server much easier to disturb to others developers on this server.  And with a web-based application, you also need to change some static files, such as  JS or CSS, so in this case you can't split changes from different developers if you use any source control system. On his own server developer have a full control on development environment. 

Only in cases, where server uses only to store some data or with so small changes of server's code, and client works via network, possible to work on single server for all developers.

1 0
Eduard Lebedyuk · Mar 5, 2016

InterSystems University Outreach Program (Russia). Each developer has his's own machine with his own Caché/Ensemble instance. We use Git source control system and there are several Studio integration plugins we offer, but mainly Cache-tort-git. Changes are commited to a central GitHub repository preferably via pull-requests (see GitHub workflow). Changes from GitHub repository are automatically pulled to a production server(s) with Cache GitHub Continuous Integration tool.

3 0
Bill McCormick · Mar 5, 2016

I strongly recommend people to each have their own system and to sync to a source control system as a preferred methodology. The one use case I have heard to justify putting a lot of developers on one box is where you are doing something like Ensemble and you have a complicated integration environment, perhaps with security restrictions that make it prohibitively difficult to replicate that set up across multiple systems. But even tasks like this become easier with tools like Vagrant that "package" an application and install it with standard customizations across multiple systems and even OSes.

Having a bunch of developers touching code in the same namespace is a perilous thing. How do you know what is production code versus something I was noodling on as an experiment this morning? Fighting over the same classes? These are all nasty repercussions of having a bunch of people editing on the same system.

4 0
Ben Spead · Mar 7, 2016

John,

I can pull back the curtain and explain the variety of ways that we handle this for Caché and Ensemble-based applications within InterSystems.  We have about 35 in-house applications based on our own technologies.  Some of them are visible to customers while a majority are internal only (as an aside, you can see which of them are available to you by going to https://login.InterSystems.com and looking at the Application Catalog which is available to you after you log in with your InterSystems credentials).  

The in-house applications are owned by a variety of teams and see a wide range of development activity - from only occationally being touched to having up to 5 or 6 developers working on the same code-base concurrently.  My team (Application Services) is responsible for providing tools, best practices and standard approaches which teams across the company can choose to adopt as opposed to reinventing the wheel.   As such, teams decide what is best for them and we have a variety of models currently in use.  

In general, we work with three environments for each application - production (LIVE), TEST and development (BASE).  Over the past few years we have moved to a model of deploying all of our LIVE servers on VMs which then enables us to clone LIVE and make TEST and BASE identical in terms of configuration, OS, etc.  This has saved a lot of time which was previously lost to surprises introduced by environments being out of sync.

With a BASE VM in place for most apps, our default work-flow is to make this a 'Shared BASE' which developers can use for their development work.  The advantages are that individual developers don't have to build out configuration and data which may impact the code they are writing (we periodically refresh BASE and TEST with the data from LIVE after appropriate scrubbing), and if a developer works with a half dozen applications they can jump in and out easily and quickly  when they need to address items across a number of applications.  Also, this makes it easier to handle things like integration (which Bill refers to above) as well as provide essentially zero ramp-up time for someone asked to jump in and help on an app for a short period.  Lastly, having a Shared BASe makes it easy for someone on call to debug code on an application which they may not normally touch.  In this model, our Studio Source Control hooks enforce only 1 developer checking out a file at a time from the Shared BASE.  

However, while this works for a majority of our applications due to the small number of developers concurrently working on the same application at the same time, we do see collissions on our most active applications with this model (because of only allowing a single developer to have a file checked out or due to different in-process changes breaking the system for others developing on it) and so we have moved other means of working in that case.  The most common is a 'hybrid' model where people can work on the Shared BASE for quick fixes, etc, but longer projects or changes which hit the most frequently edited items take place in a "Private BASE" where the developer does their work and after validation they check in their source into the BASE branch and then loads it into the Shared BASE to final development testing (this is prior to independent testing which will take place in TEST or LIVE).  In some cases the Private BASEs are per-developer namespaces on the "Shared BASE" server so that they can take advantage of common configuration and data (each developer has their own code DB but they point to the shared data DB).  In other cases developers build their own Private BASE locally and do nothing on the Shared BASE server until their code is pushed there for final BASE testing.  In the hybrid model, one developer can have a file checked out on the Shared BASE while someone else is working on the same file in their Private BASE and whoever does the check-in second will need to merge their code with the first check-in.  

Finally, we have one application which decided to have no Shared BASE at all, and instead they have a VM Template of a BASE environment for that application and each developer will spin off their own BASE VM.  This can make integration testing harder and there is no common place to test (and set-up time is much greater) so I am not in favor of this and don't generally recommend it internally to teams trying to figure out their own collaboration.  

I tend to recommend a Shared BASE as a starting point, and if a team finds that they are having confilcts due to the number of developers or level of activity I recommend that the most active developers spin off a Private BASE but leave the Shared BASE for small bug fixes, integration testing, data-driven testing or crisis debugging.   This recommendation aligns well with the home grown change control and deployment tools that we use internally and may not work well for other shops with other tools (our tools were tailored to make this model work well in order to try to maximize productivity for our internal application development activities).  

Feel free to hit me with any questions or comments on this approach :)

Ben Spead

Manager, AppServices, InterSystems

4 0