Ready! API and GIT SCM struggles

Hi All,

Just wondering if some of you could offer some advice on using Ready! API with teams where multiple team members are working on shared projects. We are using GIT as our source control management tool via the GIT integration plugin but are hitting issues where team members are losing work and in general really struggling to get consistent stability with the integration between Ready! API and GIT.

A summary of how the team is working:

We use Ready!API (1.9) in a team of testers (varying levels of technical ability) who:
• Create and update test suites
• Use each other's test suites to run tests, clone test cases
• Make occasional updates to the shared environment settings

Git SCM is used to share the project among the team members; Ready!API offers Git integration using a Git plugin which is bundled with the tool.

The team experiences many issues with the Git integration, including:
• Changes to environment and other settings being overwritten
  o Ready!API uses one file settings.xml for the settings.
  o Ready!API changes this file settings.xml every time a project is opened (should have been fixed in version 2.0, not tested yet).
  o When multiple team members have changed any (environment) settings, this causes Git merge conflicts.
• Ready!API lacks support to automatically resolve these merge conflicts and lets the users resolve these themselves using external text editors.
• With the complexity of the settings.xml files, this is beyond what can be expected of Ready!API users.

• Considerable loss of work due to disappearing and overwritten test suites
  o When multiple team members re-order or rename test suites or test cases, these changes are not correctly brought over to other team members because of merge conflicts in files named elements.order.
• Ready!API lacks support to automatically resolve these merge conflicts and lets the users resolve these themselves using external text editors.
  o We have also found many cases of the actual test suites (i.e. the actual folders) getting lost when team members synchronize their work via Git, but haven't found the root cause to this yet.
• We see commits with the missing folders successfully pushed to the Git repository, but subsequent commits by other team members don't have those folders anymore.

• In general: Ready!API's Git conflict resolution handling is implemented
  o In case of merge conflicts, Ready!API offers three conflict resolution methods:
    • Mine: this causes issues, as other's work gets overwritten by our changes
    • Theirs: this causes issues, as our work gets overwritten by other's changes
    • Recursive: this requires merges using external merging tools in many cases, which is beyond what can be expected of Ready!API's (many) users due to the complex contents of files that Ready!API uses.

In order to mitigate thes issues, we have tried the following:
1. Using external Git integration tools rather than the Ready!API plugins
  o This still has the same issues as using Ready!API's Git integration plugin, but at least does not easily allow to overwrite each other's work.
  o We experience the following issue, however:
     • Ready!API caches project files. Hence, external changes to the project files do not correctly reflect in the project.
2. Using separate composite projects, having one team member work on a project at a time
  o Besides this undermines the benefits of using Git integration to share projects, this approach also is not ideal as team members want to be able to see other's work but not to change it. This can not be enforced in Ready!API.

Is there a way to provide a smart merge conflict resolution method in Ready!API, which removes the need for team members to either choose whether to overwrite their own or other's changes or merge using external merge tools in case of conflicts. Ready!API understands the complex file structure and should be able to merge automatically in the majority of cases. In case no automated merging is possible, the user should be presented a more convenient overview of which test suites, test cases settings, etcetera should be copied from the local to the remote repository and vice versa. The current mechanisms expect too much of the internal working of Ready!API to its users.

Would be interested to hear how other teams are overcoming these challenges.

Rgds,

Frank