Tracking tools

This wiki will help the IT-SDC-MI group decide the structure that should be used for the tracking tools

Basic assumption:

  • Jira will be used to keep track of development and deployment
  • Jira will be open to end users to see the status and comment
  • GGUS/SNOW will be supported

The main discussion now is to decide if there should be a single project (with each application as a different component), or different projects per application. Other alternatives (like one project per rpm, or one project per category) have already been discussed and discarded (see Tracking Tools Presentation.

Jira concepts:

  • Category: Project belong to a category. This is used only for the initial page. Current categories: ATLAS, ATLAS ADQ, IT Databases, IT Services, IT infrastructure
  • Project:: Basic unit of jira. Roles, versions, notifications and workflows are defined at the project level. Current projects: AI, AI Monitoring, ATLAS simulation, Big Brother, CERN mobile web pages...
  • Component: Projects can be divided into components. Examples: for AI has 45 component (cli, boson, archive, apollo...), GEANT has 3 components (framework, physics, navigation), lcgutils has 12 components (davix, gfal 1.0. gfal 2.0)
  • Version: Originally, assignated to a project. Several projects put in the version the component name to which it applies

IT-SDC-MI applications

This table contains the applications that will be considered, and their current leader

Application Project leader
FTS Dashboard A.Beche
XRootD Dashboard (FAX, AAA) A.Beche
WLCG Transfers Dashboard A.Beche
ATLAS DDM Dashboard David
xbrowse David
SiteView Eddie
WLCG GoogleEarth Dashboard Eddie
ATLAS DDM Accounting Eddie
ATLAS Historical Views Eddie
CMS Historical Views Eddie
ATLAS Production Task Monitoring Eddie
ATLAS Interactive View Eddie
CMS Interactive View Eddie
CMS Task Monitoring Eddie
Common Framework Pablo
CMS Data Popularity Domenico
SAM probes Marian

Use cases

This table presents several use cases, and how they will be solved in the two approaches (one single project, one project per application)

Use case Single Project Project per application
Creation/removal of a new application Add/remove a new component Ask the jira support to create/remove a new project, replicating the workflow and basic configuration. Define developers for this application
New member in the team Add the person to the project Add the person to all the project that are needed
End user submits a ticket Submit to the project Either the end user submits to the appropriate project, or there is another project as an entry point.
Create a version of an application Use the application name and version number (might be the version of one of the rpms) as the version Use a version number (might be the version of one of the rpms)
Application developer wants finer granularity Use versions (or more components) Use components
Issue affects several applications Mark it with all the components Duplicate ticket??
Issue assigned to the wrong application Change the component Change the project
Issue notifications Everyone gets everything Issues sent only to the developers of the applications
Migrate to the other approach Supposed to be easy (to be tested) Supposed to be easy (to be tested)
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2013-11-01 - MarianBabik
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback