Uploaded image for project: 'Camunda Optimize'
  1. Camunda Optimize
  2. OPT-2107

Parallelize back-end integration test execution

    Details

    • Type: Task
    • Status: Done
    • Priority: L3 - Default
    • Resolution: Won't Do
    • Affects Version/s: None
    • Fix Version/s: 2.5.0, 2.5.0-alpha2
    • Component/s: backend
    • Labels:
      None
    • PM Priority:
      130

      Description

      AT:

      • the integration tests can be executed in parallel with a hardcoded split defined in excludesFiles

      Context:
      While adding more and more tests to Optimize, the test execution pipeline tends to take a very long time. Therefore, it makes sense to parallelize the execution so that developers don't have to wait for a very long time until they get a result.

      The follow-up ticket OPT-2191 will handle the splitting of the tests in a not hardcoded fashion.

        Issue Links

          Activity

          Hide
          johannes.heinemann Johannes Heinemann added a comment - - edited

          We had a discussion on if we actually want to do the parallelization as described in the ticket. This is the outcome of the discussion meeting that we had on the topic:

          Pros/Cons of the plugin:

          + it would solve the problem of parallelizing the tests
          + the development overhead would be very low
          + there is no need for the development team to maintain the parallelization
          + it's not needed to adjust production code
          + the splitting of the tests is done automatically
          - it would involve a large implementation afford of the SRE team
          - the plugin is likely to loose support, since there are no additional implementation commits and it's only used a 1000 times.
          - it doesn't work with our current CI infrastructure
          - the test splitting will have way more monetary costs
          - it's not possible to run the tests in parallel on a local machine
          

          Pros/Cons of the several engines+several optimizes+elasticsearch prefixes solution:

          + it would solve the problem of parallelizing the tests
          + lower monetary costs
          + it's possible to run the test in parallel on a local machine
          + other teams are doing it the same way and we could do the parallelization consistently throughout the teams
          + easy to integrate in current ci infrastructure
          + no dependency on external projects
          - very large implementation overhead for the development team
          - it needs adjustment of production code for test setup
          - needs to be maintained all the time
          - possible side effects between between the different indexes 
          

          In the end we decided to no for the several engines+several optimizes+elasticsearch prefixes solution, since the monetary costs and the high chances of the plugin not being maintained any longer, could lead to having to do the prefix solution in the end after all. This involves a lot more engineering effort. Hence, we tackle this issue in the next quarter and are closing this ticket for now.

          Show
          johannes.heinemann Johannes Heinemann added a comment - - edited We had a discussion on if we actually want to do the parallelization as described in the ticket. This is the outcome of the discussion meeting that we had on the topic: Pros/Cons of the plugin: + it would solve the problem of parallelizing the tests + the development overhead would be very low + there is no need for the development team to maintain the parallelization + it's not needed to adjust production code + the splitting of the tests is done automatically - it would involve a large implementation afford of the SRE team - the plugin is likely to loose support, since there are no additional implementation commits and it's only used a 1000 times. - it doesn't work with our current CI infrastructure - the test splitting will have way more monetary costs - it's not possible to run the tests in parallel on a local machine Pros/Cons of the several engines+several optimizes+elasticsearch prefixes solution: + it would solve the problem of parallelizing the tests + lower monetary costs + it's possible to run the test in parallel on a local machine + other teams are doing it the same way and we could do the parallelization consistently throughout the teams + easy to integrate in current ci infrastructure + no dependency on external projects - very large implementation overhead for the development team - it needs adjustment of production code for test setup - needs to be maintained all the time - possible side effects between between the different indexes In the end we decided to no for the several engines+several optimizes+elasticsearch prefixes solution, since the monetary costs and the high chances of the plugin not being maintained any longer, could lead to having to do the prefix solution in the end after all. This involves a lot more engineering effort. Hence, we tackle this issue in the next quarter and are closing this ticket for now.

            People

            • Assignee:
              Unassigned
              Reporter:
              johannes.heinemann Johannes Heinemann
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: