Home/ Questions/Q 6328333
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T17:26:28+00:00

Let say we got an android client and a java api server and code

  • 0

Let say we got an android client and a java api server
and code are commit to same svn repository with different subfolder

Svn Version 1: [Server version 1]

Svn Version 2: [Server version 1] [Client version 1]

Svn Version 3: [Server version 2] [Client version 1]

Svn Version 4: [Server version 2] [Client version 2]

Svn Version 5: [Server version 3] [Client version 2]

When developer checkin version 5, it is easy to setup buildserver and ask maven to do integration-test using latest client version2 against server version 3 code.

However we had a large group of user using version 1, we certainly need backward compatability for client version 1 in serverversion 3.

My question would be does maven/buildserver had anything build-in for this type integration-test?

For my instance I am using teamcity and maven to automate my integration test.

=======================================================

After seeking Kozelka’s recommendation, here are the way I am going to get the test automated:

Svn layout

svn repository
    client trunk
    server trunk
    released version
        client release version 1
        client release version 2

every time developer checkin to the server trunk, teamcity build would try to do “maven install” of the server code, and package it as a war artifact and install to local maven repository.

And then the teamcity will be triggered to do a checkout of client V1 branch, in the client version 1 pom, it had a dependency to the latest server artifact, and will start the jetty using the latest server artifact before the integration-test and test it using client version 1 api view.

The same thing apply to client version2 branch too and for every supported client release, will need to build a seperate sub-project in teamcity to ensure the latest server are backward comptable to old api view.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I recommend you to use branches for any version that you want to support. You can create a branch for any version that you need to maintain.

    If your test finds regression, you will commit fixes to that particular branch; with your presented scenario there is no way to make (and commit) fixes so the whole testing is much less useful.

    For SVN, branching is described here.
    In fact, it is just copying the project tree to another location (typically under /branches/) because SVN does not have separate concept of branches. Other revision control systems work differently, but no matter which of them you use, branches seem to be the way you should IMHO go.

    Probably the only “disadvantage” is that you need to maintain tests separately in each branch. If this is an issue (= you have really big number of tests), you can solve it by splitting the test code to separate modules shared across branches. But typically you will just merge commits from one branch to another to reach the same or similar functionality; this option is important when the code in branches, and their tests, deviate enough.

    • 0