1. Mandate of CO/DO section and Status/Outlook for Build tools
Vito Baggiolini CO/DO

2. Background: Work as CO TEC
Improved CO Development / Release / Deployment Workflow
Purpose: Smooth upgrades of the Controls System
ACET project (Accelerator Controls Exploitation Tools)
Better tools for operational support
Emerging discipline known as “DevOps”
Bringing Development and (IT) Operations together
Improving the process as a whole

3. Dev Ops
Exploi-tation
Develop-ment
Quality assurance
Dev Ops

4. Mandate
Provide tools for SW development, testing, release and deployment (Java and C/C++)
Provide and support operational Unix platforms
Provide better exploitation tools  ACET project
Support/promote SW engineering best practices to achieve smooth upgrades and operations

5. DO section members Nicolas DMN Alastair Bland Mike Grosak Niall
Stapley
Pavel
Tarasenko
Donat
Csikos
Jeremy
Nguyen
Steen
Jensen
Vito
Baggiolini

6. SW Development Tools for Java and C/C++
“Individual” SW development tools
GCC, JDK, 3rd party libraries
Eclipse IDE with pre-configured plugins
Issue tracking and configuration management tools
Atlassian tools (JIRA, Wikis, Fisheye, Crucible)
Build/Release tools
Maven (“Nexus”) Repository for binary artifacts
C/C++ build tool with dependency management => Jeremy
Java build tool as successor to Cmmnbuild
Testing and Quality Assurance tools
Continuous Integration server (Atlassian Bamboo)
Testbed for CO core components => Jeremy

7. Operational Unix platforms
Responsibilities:
Front-ends, backend servers, operational consoles
LynxOS and Linux
Migration away from LynxOS in LS1 and LS2
Review of how things are currently done (during LS1)

8. Better Exploitation Tools
ACET = Accelerator Controls Exploitation Tools (Project leader: Steen Jensen)
Motivation: Troubleshooting is difficult and often needs several CO experts
Areas of work:
Better diagnostic tools (first line diagnostics by non-experts (OP) , more efficient interventions by CO experts)
“Early warning system” based on DIAMON
Centralized tracing; tracing analysis tools

9. SW Engineering Best Practices
Motivation: controls system must be stable, and upgrades (during tech stops) must be smooth
LMC 103: Steve Myers asked the CO group to make a proposal how the SW change control should be done
All operational software changes (including equipment groups)
Similar requests voiced in Evian Workshop (Dec 2011)
Working group headed by me to elaborate a proposal
Related tools to be supported by DO section
LHC Machine Committee

10. Build Tools for Java Background:
Problems/missing functionality in cmmnbuild in 2009
Too much maintenance work => use 3rd party solution
Tedious management of 3rd-party libraries
Project to provide successor of cmmnbuild (Niall)
Maven was “the obvious candidate”
“Guinea pig” project C2MON (DIAMON-TIM collaboration)
Mixed experience trying to port existing CO/AP projects
Conclusion:
Maven is not the obvious choice, alternatives must be examined
But: we will use the Maven Repository (Nexus)

11. Maven Nexus Binary Repository
Industry standard (used also by other build tools)
Easy provision of 3rd party libraries

12. Plans
(Slowly) migrate from pcrops (cmmnbuild repository) to Maven Nexus
Provide interoperability cmmnbuild  Nexus
Cmmnbuild can get 3rd party binaries from Nexus
Binaries produced cmmnbuild are also copied to Nexus
pcrops remains the operational repository for 2012
Cmmnbuild build tool successor
Study and try out Gradle as alternative to Maven
Eat our dogfood internally in CO this year
Large-scale migration of clients during LS1