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
Not
daily stand-up
meetings anymore (due to COVID)
On CERN/Mattermost:
here
Planning poker, retrospectives etc ...
Methodology
Homegeneous
CI and tools rules
Directory layout, naming, styling ...
techs and frameworks
containerized build environment
Documented
templates & boilerplates (
cpp
/
web
)
guidelines
&
readmes
playgrounds
&
live-documentation
Formal
documentation streams
and
tooling
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
Large number or repositories and users
Enforced using
automated tools
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
For web-applications using
CERN/OpenShift
For middleware using
packages
(deb, RPMs) and Puppet
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