1. BE-CO-DO - Development tools (Eclipse, CBNG, Artifactory, …) - Atlassian (Jira, Wikis, Bamboo, Crucible), CO Testbed - DIAMON/LASER - JMS (Java messaging middleware) Vito Baggiolini (with input from the DO section members)

2. What did the LS1 mean for our services? Devtools + Atlassian: we had more work, less operational urgency More people actively did development  higher support load Developers were more “adventurous” (did more radical changes, touched code that was frozen, tried new things)  more consulting and more difficult support requests We had (almost) no services to provide to OP  lack of “operational urgency” LS1 was a bad moment to do major changes, tools have to work DIAMON/LASER: LASER was used by TI operators, same operational expectations as during the RUN DIAMON was not operational, but expected to be running, e.g. by equipment groups Good moment to work on DIAMON “There never is a good moment to do changes in LASER” JMS: The main, general purpose brokers had to run Dedicated brokers (e.g. InCA, Sequencer) were left running LS is the best (only?) moment to upgrade the JMS servers and libraries 01/12/2015Vito Baggiolini for CO-DO - LS1 review2

3. How did we prepare for LS1? DevTools, Atlassian: we did no special preparation We provided existing services and tools as usual But: we underestimated the support load [We were working on the new build system (CBNG), of which the release date was not directly correlated to LS1] LASER/DIAMON We made sure we had validated DIAMON-2 core before LS1 during operational periods Our plan was to make it simple to configure and more user friendly, which depended on CCDB, which didn’t work out. JMS Candidate new JMS versions were tested during RUN1 with operational load 01/12/2015Vito Baggiolini for CO-DO - LS1 review3

4. What worked well in LS1, for the service we ran? We managed to provide reasonable services to our clients Atlassian suite: We provided special support for MCCs and dry run organization We managed to provide the necessary service for a growing number of teams Testbed: Initially not used, but later a crucial service for quality assurance for FESA and RDA We pragmatically shared responsibility between (1) DO and (2) FESA and RDA teams Commonbuild By and large, we provided a good service to our clients, but we did not extensions (e.g. FESA3 Java beans) DIAMON/LASER We managed to keep TI operations up and running JMS We successfully kept the main JMS brokers running 01/12/2015Vito Baggiolini for CO-DO - LS1 review4

5. What didn’t work well with our services? We had to dedicate too much time and priority to support This time was missing elsewhere, i.e. in CBNG. Devtools OP and other GUI developers suffered from dependency problems (Jar Hell) Our self-service tools were not good enough, we had to give face-to-face support Atlassian A couple of incompatible changes in IT which caused down time (certificates, DB upgrades) Wikis search was and is unsatisfactory JIRA E-mail handler didn’t work reliably We had to say “No” more often than we would have liked to The first attempt to bring out CBNG was unsuccessful (Independent of LS1) TE-MPE decided to use CBNG as early users We were not yet ready and could dedicated too little manpower to it Most visible problem: many inconsistent dependencies in the CBNG repository We did not integrate FESA 3 code generation into CommonBuild 01/12/2015Vito Baggiolini for CO-DO - LS1 review5

6. What didn’t work well with services we depended on? DIAMON/LASER team suffered from overload of CCDB team Were hoping to make the configuration tools more user friendly e.g. expected new/better configuration editors from CCDB team This was downgraded to lowest priority at the beginning of LS1 LASER struggled to remain operational because of underlying changes Underlying systems (e.g. Middleware, FESA, Classes) were much less reliable than during the RUN Many non-backward compatible changes done (e.g. renaming or devices/properties) Radical change in alarms concepts (e.g. alarms became multiplexed)  Team spent a lot of time troubleshooting and fixing things The collaboration around SIP4C++ did not make enough progress We considered ourselves to be enablers, organizing meetings and fostering collaborations between the 3 main C/C++ teams (FESA, RDA, TIMING) The 3 teams did not have enough time to participate and adapt to agreements made. 01/12/2015Vito Baggiolini for CO-DO - LS1 review6

7. Planning, organization, communication, testing Devtools: We needed to provide a stable service, therefore we rolled out small changes in a continuous back-compatible way. We had no particular communication needs. Atlassian We occasionally needed down-time for maintenance/upgrades We communicated by e-mail + banners in the web applications Support re-organization for Devtools and Atlassian We struggled because of the high number of support requests and interruptions We reacted by introducing e-mail list and organizing support-rota, with escalation We started to do daily stand-ups to better coordinate our work We started to use Kanban to visualize all work (development and support) Diamon/Laser: As during operational periods Announcement in TIOC, upgrades in agreement with OP(-TI) 01/12/2015Vito Baggiolini for CO-DO - LS1 review7

8. How do we perceive LS2? Draft plans for Work Devtools need to be ready at the beginning of LS2 We will prepare during the RUN Work planning will be influenced by outcome of this review We will soon organize a “Monitoring review” DIAMON/LASER and many other monitoring activities and functionality Purpose: identify redundancies/synergies Work towards the next generation of monitoring/diagnostics with all parties involved During RUN2, we (will) promote use of Tracing to collect usage information Gather information of what has been used by whom (apps, jars, libs, devices, …) As a basis for cleaning up and EOL enforcement during LS2 We will do a review of tools/technology we have been using for some time to see if we want to replace any (Atlassian tools, Eclipse, SVN, JMS, …) 01/12/2015Vito Baggiolini for CO-DO - LS1 review8