Software Version Management as part of the Development Process for Application Software

1. Software Version Managementas part of the Development Process for Application Software Eugenia Hatziangeli for the Application Section based on work contributions fromEric, Greg, Lionel, Petter, Vero, Wojtek and several technical students CERN AB Controls

2. Some Terms • Development process covers all activities from the moment a developer starts a new project to the moment the resulting system is delivered in operation • development, operation, maintenance, … • SoftwareConfigurationManagement is a methodology to manage a software project through its developmentprocess • Softwareversioncontrol is the management of multiple versions of the same unit of source code

3. Development Process • Projects and code organization • Source versioning management • Build services (automation of common tasks) • Compilation, JAR • Documentation generation • Dependencies management • Release version management • Releasing new versions of software in operation • Applications deployment • Issues & bugs tracking (guidelines, naming conventions, directory structure) http://cern.ch/ab-dep-co-ap/dev/ (CVS) (JIRA)

4. Build software release PCROPS Install software release Multi-version Operational Software distribution repository Complete releases with sources CVS Installation procedure Build procedure Distribution procedure Bug Reports Check out Check in Distribute production software Making the installed product available to be used for production jars, configuration, libraries,includes, startup scripts, doc, etc. Maintenance procedure Deployment procedure Change Requests User Development Area Development Process

5. Build software release PCROPS Install software release Multi-version Operational Software distribution repository Complete releases with sources CVS Installation procedure Build procedure Distribution procedure Bug Reports Check out Check in Distribute production software Making the installed product available to be used for production jars, configuration, libraries,includes, startup scripts, doc, etc. Maintenance procedure Deployment procedure Change Requests User Development Area Developing Software

6. CVS structure

7. Build software release PCROPS Install software release Multi-version Operational Software distribution repository Complete releases with sources CVS Installation procedure Build procedure Distribution procedure Bug Reports Check out Check in Distribute production software Making the installed product available to be used for production jars, configuration, libraries,includes, startup scripts, doc, etc. Maintenance procedure Deployment procedure Change Requests User Development Area Building Software

8. Building Java - the tasks • Simple • Transform .java to .class • Package to .jar • Generate Javadoc • More complex • Execute unit tests • Perform code quality checking (code convention, auditing) • Generate documentation • Publish to a web site • Manage dependencies with other jars • Deploy to an application server • Integration of code generation (XDoclet, JAPC codegen) • Nightly build • etc…

9. Using a Common Build serviceIt makes sense • It provides a central place for the complex tasks • Users are calling high level services and do not write them • The build service provides added value for managing dependencies in a seamless way • The integration with 3rd party services is done • Existing open source solutions (Maven, Centipede) • Not mature enough at that time • Could be potential solutions in the future We developed our own common build service

10. Our CommonBuild • Based on Apache Ant • Java based open source build tool (like Make) • XML based build file defining targets • Functionality • Provides predefined targets for everything needed • Compilation, release, packaging (JAR), testing, branching, .. • Documentation generation • Code quality • Unit testing • Source code & specific descriptors generation • Prevents Copy/Paste errors • Integration with 3rd party tools (CheckStyle, JUnit, JDepend, XDoclet, Forrest, Java2Html, Jjar, …) • Minimizes startup effort for a new project • Used by all AP projects and more

11. equipstate/ people build.xml product.properties product.xml src/ java/ test/ Organization of a project(Directory structure) Doc: http://cern.ch/ab-dep-co-ap/dev/

12. equipstate/ people build.xml product.properties product.xml src/ java/ test/ CommonBuild files(Release check list) Specifies who has the right to release this productList of usernames ex: gkruk

13. equipstate/ people build.xml product.properties product.xml src/ java/ test/ CommonBuild files(Build file) Ant’s default build file thatimports targetsfrom CommonBuild

14. equipstate/ people build.xml product.properties product.xml src/ java/ test/ CommonBuild files(Services file) Specifies the services to activate in CommonBuild during the build process e.g. JavaDoc generation, unit tests, specific descriptors generation ex: javadoc.enabled=true

15. equipstate/ people build.xml product.properties product.xml src/ java/ test/ CommonBuild files(Product’s descriptor) Descriptor of the product and its directdependencies <products> <product name=”equipstate" version=“0.1.0" directory=”lsa/equipstate"> <desc>equip state application part of the lsa suite </desc> <dependencies> ….. … </dependencies> </product> </products>

16. Dependencies management Production 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> No version means depends on default version of product A The dependencies are resolved to actual version numbers

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

18. Build software release PCROPS Install software release Multi-version Operational Software distribution repository Complete releases with sources CVS Installation procedure Build procedure Distribution procedure Bug Reports Check out Check in Distribute production software Making the installed product available to be used for production jars, configuration, libraries,includes, startup scripts, doc, etc. Maintenance procedure Deployment procedure Change Requests User Development Area Release of Operational Software

19. Release of Operational Software • Operational software is released in a central distribution area in a multi-versioned repository • pcrops is the owner of this repository

20. Release Management Release Tool • Automates the process of building and installing a software productfrom CVS into the distribution area • Basic GUI for clients or cmd line • Based on Ant • Both for Java and C/C++ products • Independent of CommonBuild

21. What Release does • Extracts the product from the central CVS to a new version directory within the PCROPS distribution repository • Builds the product for all supported systems • Installs it in a multi-versioned repository • New version is added without modifying the old ones • Possible to access any available operational version of a product • Updatesproduct aliases (symbolic links) • Assigns new version as production (PRO) or next (NEXT) • Keeps the previous production version (PREVIOUS) • Possible to revert to previous versions of a product

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

23. Build software release PCROPS Install software release Multi-version Operational Software distribution repository Complete releases with sources CVS Installation procedure Build procedure Distribution procedure Bug Reports Check out Check in Distribute production software Making the installed product available to be used for production jars, configuration, libraries,includes, startup scripts, doc, etc. Maintenance procedure Deployment procedure Change Requests User Development Area Deployment

24. Applications Deployment • Java Web Start (JaWS) is used for deployment • 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 • pcrops contains all libraries and JNLP files • CommonBuild supports applications deployment • generates the JNLP file • creates a command-line script to start tasks • A Web server enables deployment via Java Web Start • http://<webserver>/ap/dist/lsa/equipstate/PRO/equipstate.jnlp • Once a new application is released in pcrops, restart the application is sufficient for JaWS to redeploy automatically the new application locally on the operational console

25. Summary • A solid automated development process is in place • A suite of integrated tools, an infrastructure and gooddocumentation are available to support the process • The development path is shorter and simpler • The process and the tools have been validated by several projects