1 / 19

G.Kruk L.Mestre, V.Paris, S.Oglaza, V. Baggiolini, E.Roux and Application Section developers

Development Process of Accelerator Controls Software. G.Kruk L.Mestre, V.Paris, S.Oglaza, V. Baggiolini, E.Roux and Application Section developers. Agenda. Development process Issues How we addressed them? Conclusions. Development Process.

lola
Télécharger la présentation

G.Kruk L.Mestre, V.Paris, S.Oglaza, V. Baggiolini, E.Roux and Application Section developers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Development Process of Accelerator Controls Software G.Kruk L.Mestre, V.Paris, S.Oglaza, V. Baggiolini, E.Roux and Application Section developers CERN AB Controls

  2. Agenda • Development process • Issues • How we addressed them? • Conclusions

  3. Development Process All activities from the moment a developer starts a new project to the moment the resulting application is running on operational consoles in the control room Operational Consoles

  4. Context in CERN Controls • 2002 • Support for C developments (under control of Make) • No Java development process in place • Java based on small interdependent products • ~ 130 products which use about ~140 external libraries • Dependencies tree very complicated – up to 10 levels • ~ 30 developers • Need for supporting tools • No mature solution on the market • Work started on custom solution

  5. Development Process Issues • Projects and code organization • Source versioning management • Build services (automation of common tasks) • Compilation, JAR • Documentation generation • Dependencies management • Release management • Releasing new versions of software in a dedicated repository • Applications deployment • Issues & bugs tracking (guidelines, naming conventions, directory structure) (CVS) (JIRA)

  6. Build services : Common-Build • Based on Apache Ant • Java based open source build tool (like Make) • XML based build file defining targets • Functionality of Common-Build • Provides predefined targets for everything needed • Compilation, packaging (JAR) • Source code & specific descriptors generation • Documentation generation • Code quality • Unit testing • Prevents Copy/Paste syndrome • Integration with the infrastructure in place • Minimal effort to start

  7. Target examples • Compiling sources • ant compile • Building distribution of the product • ant dist • Releasing new version of the product • ant release

  8. equipstate/ build.xml product.properties product.xml people src/ java/ test/ Common-Build constraints(Directory structure)

  9. equipstate/ build.xml product.properties product.xml people src/ java/ test/ Common-Build constraints(Build file) Regular Ant’s build file that imports targets from Common-Build (always the same)

  10. equipstate/ build.xml product.properties product.xml people src/ java/ test/ Common-Build constraints(Services file) Specifies the services to activate in Common-Build during the build process e.g. JavaDoc generation, unit tests, specific descriptors generation

  11. equipstate/ build.xml product.properties product.xml people src/ java/ test/ Common-Build constraints (Product’s descriptor) Descriptor of the product and its directdependencies

  12. equipstate/ build.xml product.properties product.xml people src/ java/ test/ Common-Build constraints(Release check list) Specifies who has the right to release this product

  13. Dependencies management Production repository 3rd party repository Product A Lib B Lib A equipstate product.xml <product name=“equipstate” …> <!-- … --> <dependencies> <dep product=“LibA” version=“1.2.8” /> <dep product=“ProductA” /> </dependencies> </product>

  14. equipstate/ build.xml product.properties product.xml people lib/ LibA.jar ProductA.jar LibB.jar src/ java/ test/ Production repository 3rd party repository Product A Lib B Lib A equipstate Dependencies management equipstate/ build.xml product.properties product.xml people src/ java/ test/ ant getjars

  15. Release Management Release Tool • Also based on Ant • Both for Java and C/C++ products • Can be used without Common-Build

  16. What Release does • Extracts the product from the CVS to the dedicated production repository • Builds the product (calling Common-Build) • Installs it in a multi-versioned repository • New version is added without modifying the old ones • We can always use old versions • Updates product aliases (symbolic links)

  17. Release management(Production repository) • Aliases: • PRO - production version • PREV - previous versions (version which was replaced by PRO) • NEXT - next version to be tested before becoming PRO dist accsoft macsy leir client equipstate domain PRO PREV NEXT 0.5.1 0.5.2 0.6.0 0.6.1

  18. GUI Applications deployment • We use Java Web Start deployment technology [TH3A.2-50] • uses a special XML descriptor (JNLP file) to deploy and run applications • ensures that all required libraries (cached locally) are up to date • JNLP file specifies • how to run the application • where required libraries are found • Repository contains all libraries and JNLP file • We added a Web server to enable deployment via Java Web Start • http://<path_to_the_dist>/macsy/equipstate/PRO/equipstate.jnlp

  19. Conclusions • We put in place a very solid development process • The whole process is automated now • We have a suite of integrated tools supporting the process • We succeeded to make the deployment path short and simple • This has been validated operationally

More Related