0

I have a Java-based server, transmitting data from many remote devices to one app via TCP/IP. I need to develop several versions of it. How can I develop and then dwell them without need in coding for 2 projects?
I'm asking not only for that project, but for different approaches.

Natalia
  • 783
  • 7
  • 18
  • It depends. What's the difference between the versions? Anyway, the most sensible idea seems to use a code versioning system and use branches. – toniedzwiedz Jun 25 '12 at 06:47
  • Main server won't recieve data from unknow devices and will send time for synchronization, other - won't. But it's for now. May be in future difference will grow more.
    I'm asking not only for that project, I'm asking for possible approaches.
    Can you write some details about approach you've mentioned?     – Natalia Jun 25 '12 at 07:06
  • if several versions on the remote devices need to talk to the same java server, you need to work the version into the protocol you use for communicating. – Gertjan Assies Jun 25 '12 at 07:08
  • Yes, that's what I did, but what about different versions of server? – Natalia Jun 25 '12 at 07:09

4 Answers4

1

Where the behaviour differs, make the behaviour "data driven" - typically by externalizing the data the drives the behaviour to properties files that are read at runtime/startup.

The goal is to have a single binary whose behaviour varies depending on the properties files found in the runtime environment.

Java supports this pattern through the Properties class, which offers convenient ways of loading properties. In fact, most websites operate in this way, for example the production database user/pass details are never (should never be) in the code. The sysadmins will edit a properties file that is read at start up, and which is protected by the operating system's file permissions.

Other options are to use a database to store the data that drives behaviour.

It can be a very powerful pattern, but it can be abused too, so some discretion is advised.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • Yeah, if your differences will only be in the set up, then just make different properties files. Otherwise, if there will be code differences, you should use an SCM and use different branches. – carlspring Jun 25 '12 at 07:42
  • @carlspring No, I'm saying make the code differences data driven too if possible. For example, simple java code like `if (someProperty) doVersion1(); else doVersion2();`, through to using `Class.forName()` to load the implementing class based on the value of a property – Bohemian Jun 26 '12 at 01:31
0

Make any other version based on previous one by reusing code base, configurations and any other asset. In case if several versions should be in place at one time use configuration management practices. Probably you should consider some routing activities and client version checks on server side. This is the place where 'backward compatibility' comes to play.

Viktor Stolbin
  • 2,899
  • 4
  • 32
  • 53
0

The main approach is first to find and extract the code that won't change from one version to another. The best is to maximize this part to share the maximum of code base and to ease the maintenance (correcting a bug for one means correcting for all).

Then it depends on what really changes from one version to another. The best is that on the main project you can use some abstract classes or interfaces that you will be able to implement for each specific project.

YMomb
  • 2,366
  • 1
  • 27
  • 36
0

I think you need to read up on Source Control Management (SCM) and Version Control Systems (VCS).

I would recommend setting up a git or Subversion repository and adding the code initially to trunk and then branching it off to the number of branches (versions you'll be working on).

The idea of different versions is this: You're developing your code and have it in your SCM's trunk (or otherwise known as a HEAD). At some point you consider the code stable enough for a release. You therefore create a tag (let's call it version 1.0). You cannot (should not) make changes to tags -- they're only there as a marker in time for you. If you have a client who has version 1.0 and reports bugs which you would like to fix, you create a branch based on a copy of your tag. The produced version would (normally) be 1.x (1.1, 1.2, etc). When you're done with your fixes, you tag again and release the new version.

Usually, most of the development happens on your trunk. When you are ready with certain fixes, or know that certain fixes have already been applied to your trunk, you can merge these changes to other branches, if necessary.

carlspring
  • 31,231
  • 29
  • 115
  • 197
  • This is more about support and bug fixing, isn't it? Not about adding some functionality to one branch and other functionality to other branch. I need to release several different versions at the same time, and then maybe fixing bugs for all of them. Is ot possible with Subversion or other systems? – Natalia Jun 25 '12 at 09:39
  • Yes, it is possible. Both with git and Subversion. :) – carlspring Jun 25 '12 at 10:11