Versions Compared

Old Version 32

changes.mady.by.user aditya puthuparambil

Saved on

compared with

New Version 33

changes.mady.by.user aditya puthuparambil

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#DescriptionNotesProsCons
1

Each component contains its own docker-compose file listing all the services required for the integration test. Eg : cps-temporal docker-compose would have services  from cps-temporal as well as cps-core

As all the services are included in the docker-compose of cps-temporal, CSIT test setup could directly trigger :

      docker-compose up


  • Faster implementation
  • Every change made in a single service would have to be duplicated in all the other files where the same service is used like addition of new environment variables.
  • Harder to maintain
2 Each component contains its own docker-compose file with the services required for stand alone testing. Eg: cps-temporal docker-compose only containing services cps-temporal, timescaledb, zoopkeeper and kafka. 

As cps-temporal is a client using cps-core, include steps to fetch the docker-compose of cps-core in the cps-temporal setup.sh file in CSIT as shown below:

      git clone https://github.com/onap/cps.git

Combine the docker-compose of cps-temporal and cps while executing 'docker-compose up' 

     docker-compose -f docker-compose.yml -f ../cps/docker-compose/docker-compose.yml up

Subsequent files override and add to their predecessors. For the CSIT test cps-temporal docker-compose could override the properties specified in cps-core docker-compose.

Eg : if the notification.data-updated.enabled=false by default in cps-core docker-compose. By adding the below code in cps-temporal, these values could be overriden

cps-and-ncmp:
   notification.data-updated.enabled: 'true'
  • No need for code replication.
  • docker-compose files specific to each component
  • Cloning the dependent repo

  • The configuration to run a test does not belong to the test itself anymore as it stays in another repo. 

3Create a repo for all the common artifacts like the CSIT, documents. Sub modules could be created for different components inside CSIT to include both the docker-compose and test plan.

Eg: cps-temporal CSIT would combine the docker-compose of cps-temporal and cps-core while executing 'docker-compose up' as below :

     docker-compose -f docker-compose.yml -f ../cps/docker-compose.yml up

  • No need to replicate the docker-compose
  • docker-compose files specific to each component maintained in different sub modules
  • No cloning required for the dependent repo to run CSIT
  • ci-management jobs will have to be created, hence time consuming for now
  • Manageability of an additional repo .


Note: Integration Test Plan included at CPS Integration Test - Developer Wiki - Confluence (onap.org)