Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
Mandate of CO/DO sectionand
Status/Outlook for Build tools
Vito Baggiolini CO/DO
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
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
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
Dev Ops
Quality assurance
Develop-ment
Exploi-tation
DevOps
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
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
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
DO section members
NicolasDMN
AlastairBland
MikeGrosak
NiallStapley
PavelTarasenko
DonatCsikos
JeremyNguyen
SteenJensen
VitoBaggiolini
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
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
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
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)
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
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
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
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
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
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)
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-12
Maven Nexus Binary Repository
• Industry standard (used also by other build tools)• Easy provision of 3rd party libraries
Vito
Bag
giol
ini C
O/D
O 1
0-Ja
n-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