1. JRA1 Meeting – 09/02/2004 - 1 Software Configuration Management and Integration EGEE is proposed as a project funded by the European Union under contract IST-2003-508833 Alberto Di Meglio EGEE Integration Manager

2. JRA1 Meeting – 09/02/2004 - 2 Summary SCM and Integration Activities First step: Developing the Master Plan Second step: Implementing the Plan Third step: Running the Backstage SCM Discussion Topics

3. JRA1 Meeting – 09/02/2004 - 3 SCM and Integration Activities EGEE has a dedicated team for SCM and Integration activities The vision of the team is that integration must start even before a single line of code is written and must provide an integrated development and collaboration environment The mission is to is to provide a solid, reliable infrastructure to manage changes and release quality software based on standard SCM procedures and tools Preparation activities are starting now and we want all parties to be involved in the process of defining the infrastructure and learn from past experiences SCM is not about setting rules, it’s about collaboration

4. JRA1 Meeting – 09/02/2004 - 4 First step: Developing the Master Plan A master SCM Plan is being formalized now It contains basic principles and rules about the various areas of SCM and Integration (version control, release management, build systems, bug tracking, etc) We want to involve all the parties in the process from developers to end users to make sure everybody “buys in” When input is collected and plan is formalized it will be circulated to get the final agreement

5. JRA1 Meeting – 09/02/2004 - 5 Second step: Implementing the Plan After the SCM Plan is formalized and published (at least an initial agreed version), we will start the implementation phase All tools, machines and communication channels will be put in place Developer’s and User’s Guides will be produced with clear instructions about how to use and interact with the project and manage changes in the correct way

6. JRA1 Meeting – 09/02/2004 - 6 Third step: Running the Backstage For the duration of the project, the integration team will: Enforce and support all procedures by means of automation tools Run the automated and manual operations of the build and release management processes Deliver integrated installation packages for all supported platforms for further testing and deployment Collect further input from all parties and introduce changes in the procedures and tools as necessary

7. JRA1 Meeting – 09/02/2004 - 7 Version and Configuration Control Based on CVS (using central IT CVS service?) Fixed directory structure for each module Rules for tagging and branching (e.g. bug fix branches) Common naming conventions for baseline and release tags Configuration files to automate creation of workspaces Used to enforce build reproducibility Used to create reference private workspaces for developers to develop against Authorization based on commitavail and tagavail according to SCM roles (developers, release managers, integrators, etc.) Supported protocols: K4, SSH (pserver only for anonymous read-only)

8. JRA1 Meeting – 09/02/2004 - 8 Automated Build System Several tools under evaluation Most interesting combination so far: CruiseControl + Maven CruiseControl runs centrally on standard Ant files, developers do not need to add/maintain other special files, works for Java, C/C++, Python, etc (using built-in or custom tasks) Ant file structure should be discussed to have a set of common items (style checks, coverage tests, unit tests, etc) Build artefacts from each module should be copied to a common local repository for resolving dependencies Maven implemented centrally to produce all project documentation and enforce additional checks and collect project metrics (need collaboration from developers to produce the Maven project files) Builds are run centrally every night (HEAD), every week (project specs) and when needed (staging build server) Developers can run private builds by using the integration Ant scripts

9. JRA1 Meeting – 09/02/2004 - 9 Defect Tracking System Bugzilla-like tool provided as part of the Savannah project portal Provided and supported by SPI team at CERN Need to add tools for collecting QA metrics (current reporting in Savannah/Bugzilla is not sufficient)

10. JRA1 Meeting – 09/02/2004 - 10 Quality Assurance Software Metrics are collected as part of the build process Software Defect and QA Metrics are collected from the defect tracking system (manually? Can SPI provide additional tools?) Project Metrics? Should we provide them in Integration? (project completion rate, labour rate, etc). It can be done, but needs input from Project Management

11. JRA1 Meeting – 09/02/2004 - 11 Change Control Board Changes must go through a formal approval process The CCB is tasked to collect and examine the change requests Changes must be tracked (in Bugzilla?) and communicated as efficiently as possible The role of the CCB (and SCM in general) is not to prevent change, but to organize it so it has only positive impacts on the project Should meet periodically Need to define composition of the board

12. JRA1 Meeting – 09/02/2004 - 12 Collaboration Tools Project Portal: Savannah from CERN SPI Single entry point for the project, news, tools, documentation Links to other relevant sites (CVS web browsing, builds status, package repository, project metrics and other artefacts) Mailing lists? News, RSS feeds, etc.?

13. JRA1 Meeting – 09/02/2004 - 13 Additional Topics to be discussed Supported platforms Supported compilers, libraries, etc Package, deployment and installation requirements for integration Roles and responsibilities