Tips for maintaining code remotely

[sthomas]

Hi All,

I have always wrote and maintained code for in-house applications.  We all know the benefits of maintaining code locally.  My company was bought out by a much larger company and they want to duplicate some of our automation in other locations.  Does anyone have any good tips/resources for error handling, debugging, and other issues that arise when the code is in a remote location?  Any help is greatly appreciated!

[mmurray]

I also have the issue of having to troubleshoot from a remote location, with the added complication the other end does not speak my language.  Several things have helped me over the years, pictures of the failure, sometimes a video, a good VPN connection that I can get into the computer and look around. I also maintain a spare test fixture that can be shipped quickly along with spare DAQs and power supplies. Once a year I travel to the site to see for myself and to do maintenance on the equipment. I bring with me a notebook computer with a license to LabVIEW so that I can fix any of the difficult problems that I could not from home.

It is a difficult task, if you come up with any new ideas I would love to hear them.

[PCorcs_DMC]

Hello sthomas,

As an integrator, this is a very common situation for us. We have numerous applications and code bases distributed to many locations. Here's a few things to consider:

1. (Probably Obvious, but...) Establish a reliable Remote Connection Option.

There are many remote desktop/support resources out there. Some companies already have contracts to use those tools, typically managed by the IT group. I would start there, becasue whatever you choose will have to be blessed by IT. Some options to check out: RealVNC (https://www.realvnc.com/), LogMeIn Rescue, Citrix GoToAssist. You can also use native Windows remote desktop if you have the proper VPN connections established with your remote locations.

2. Establish Source Code Control

If you are not already, you should immediately begin using source code control to manage your software. Again, you may need to enagage IT to establish server resources to commit to managing your code base. The good news about source code control is that these systems are IT friendly, secure, and there are many Free open source options. Popular options include: SVN (TortoiseSVN popular Windows Client), Git, Mercurial. Also, as with remote support resources, you may check to see if the company is using any of these tools already.

The main remote advantage to using a server side source code control solution is that it will allow you to work on software changes locally, upload to the server, and have someone pull them down to a remote location. This works for executable code, as well as source code.

3. If possible, have a local hardware setup that replicates the field.

If you can have a duplicate type of system, or simulation option locally, it will maximize your productivity locally. Probably enough said there.

4. Set support boundaries.

If you are the owner of the code, make sure that individuals in the field have a clear support path. For a couple of reasons: first, you wnat to hear about problems as they arise. Secondly, you want to ensure theres an option aside from a cell phone call at 3am any given day of the week. Not much specific advice here, this laregly depends on the application. Just be sure you give it some thougth before deployment.

5. Software only debugging logs.

Make sure your code has a self reporting feature. Ultimately, you will lose details when problems are commicated. If an end user can send a log file, it will dramatically help explain the behavors they will describe.

6. Sign up for frequent flyer rewards...

No matter what, the day will come where you have to be there to make sense of the situation. Be prepared, get your airline miles.

Here's another discussion of this type of work: http://lavag.org/topic/16860-interested-in-hearing-from-programmers-who-work-remotely/?hl=%2Bcoding+... with a really special cat picture closing down the discussion.