FESA3 Database Integration

At GSI exist different needs and wishes concerning the FESA3 database. This is a summary of the ideas on how to integrate the FESA3 database @GSI.

Status Quo

The FESA design documents are added to the database during the deployment process. The current implementation @CERN requires an increase of the version number of each FESA document whose content is supposed to be in the database. The reason is to ensure that no change of the interface of a FESA class (e.g. additional or removed properties, data types etc) will be undetected.

At GSI the deployment of FESA software via the FESA Eclipse plug-in is frequently used during the development of a FESA class. To increase the version number of the FESA design documents every time a small, probably insignificant change was performed is a time consuming matter as this involves the class design, the deploy-unit design and the instantiation document. Therefore a different approach is desired @GSI concerning the integration of the FESA3 database.

Requirements

• At a certain stage in the workflow developing and deploying FESA software the FESA database must be filled with information about the FESA software for usage by LSA's data management etc
• FESA software in development (test) AND productive state must be known by the database
• FESA class developers must be able to develop their software without obstacles such as constantly increasing the version numbers even for insignificant changes in test software
• Information of productive FESA software may not be overwritten in the database, one way to ensure this is to force the increase of the FESA software version number during deployment

Ideas and Suggestions

1. Optional usage of the FESA3 database, technically possible via expert option. The database will be filled on request only.
   • Advantages: independent of FESA class state (development or production), lightweight
   • Disadvantages: if a FESA class is productive a database entry might be missing if the FESA developer constantly skipped the database during deployment; GSI-specific feature that has to be tended in parts of the core package
2. Usage of a test- and a production- database, the test database allows overwriting of already existing FESA class versions whereas the productive database requires version changes during each deployment.
   • Advantages: During the deployment phase only the state of a FESA class has to be distuingished
   • Disadvantages: two separate databases required and two separate CMW nameservers for each environment, this will conflict with the application software that does not know where a device is running
3. Usage of the database for productive FESA software only, database entries are skipped during deployment of test software, productive software requires increase of version number during every deployment
   • Advantages: leightweight, GSI specific
   • Disadvantages: test software has to be added manually to the database, initially and every time the interface has changed
4. Check during deployment of FESA software which information is already in the database and compare the versions and the interfaces
   • Advantages: elegant, GSI specific but might be interesting for CERN too
   • Disadvantages: requires effort by database developers to provide functionality for retrieving information, additional checks in the FESA Eclipse plug-in required; additional checks may cause slower deployment
5. Make use of FESA class/deploy-unit state "inUse", a possible meaning could be the software is "productive for testing by AP", but not in operation yet. FESA software marked as "inUse" or "productive" will be put into the database. FESA software marked as develeopment will not be put automatically into the database during deployment.
   A new workflow is recommended for FESA developers:
   • To provide a test version for AP switch the state to "inUse", deploy this to the FEC and the database
   • Switch the state back to development and increase the FESA software version number. Develop freely without restrictions...
   • If a new development is ready for testing by AP or even for production make sure the FESA software version number is higher than the previously deployed version and switch the states accordingly before deployment.
   • The steps described above are reversible and repeatable.
   • Advantages: looks like a clean way to satisfy several needs
   • Disadvantages: version update procedure in the Eclipse plug-in may be cumbersome as several steps are required (update versions of affected FESA design documents, synchronize code, compile class(es) & deploy-unit, ); usage of yet another state

-- SolveighMatthies - 19 Aug 2014

• RE_FE_Int-Team_meeting_minutes_-_Versionsnummer.msg: Email communication so far