BE-CEM-MRO workflow (TeamA)

Sylvain Fargier (BE-CEM)

08/12/21

n_ToF consolidation

  • n_ToF : It is designed to study neutron-nucleus interactions for neutron energies ranging from a few meV to several GeV

 

  • LS2 In numbers
    • ~400 tickets (closed during)
    • 60 git repositories
    • 3 developers (fulltime)
    • >>95% uptime (24/7 activity in 2021)
    • 36 cards, 7 DAQs, 6 servers, 8 control-room machines ...
    • A lot of physicists and an awesome team !

n_ToF consolidation

n_ToF overview

n_ToF DAQ overview

n_ToF overview

n_ToF overview

Team organisation & Workflow

  • Agile/Scrum oriented
    • 4 weeks sprints
  • Using Kanban board:
    • Aggregating several projects
    • Using CERN/Jira: here
  • Dailies
  • Planning poker, retrospectives etc ...

Methodology

Projects & Repositories

  • Peer-review oriented workflow
    • Using CERN/GitLab merge-requests
    • Relying on CI tests and analysis results
  • Per component maintainers
    • to empower and give sense of responsibility to developers
  • Homogeneous workflow rules

Workflow

  • Weekly code-review
    • Show your work to others
    • Open discussions and exchanges
  • Weekly builds
    • Rebuild and validate everything
    • Dependencies, platforms, environment evolves,
    • "Better fix sooner than later"
  • Pair coding and reviews
    • Since software is all about learning

Workflow

Playground code examples

Deployment & Production

  • Automated deployments
  • Roles separation
    • Developers are not admins but can trigger software deployment
  • Traceability and reproducibility
    • Version tag based (v1.x.x)
    • Deployed from versioned build environments

Deployments & Production

  • Project specific development environment
    • Container based using MRO/x-builder utilities
    • Identical to build environment used for production
    • No setup time required and identical results for all developers, project switch requires no setup/preparation time
  • Protected production environment
    • alpha/beta/production deployments for web-applications
      • container based, end-user validation and pre-production testing
    • Puppet based deployments for middleware
      • enforces deployed configuration and packages

Env. & Deployments

Web-techs

  • Foreword: Stateful vs Stateless
    • Introduction from red-hat
    • Using a stateless back-end means that it has no internal state
      • Eases redundancy and parallelism paradigms
      • Eases debugging and investigations (context is easy to re-build)
      • It doesn't mean that the application itself has no state, other means can be leveraged: cookies, localStorage etc...
      • It simply means that every-time the back-end is solicited, the complete context is sent along with the request
    • Both patterns are used in our applications depending on the need

Web-techs

BE-CEM-MRO workflow

By Sylvain fargier

BE-CEM-MRO workflow

  • 250

More from Sylvain fargier