Let there be DevOps · e.g., OpenStack Horizon CLI e.g., OpenStack CLI Config. management e.g.,...
Transcript of Let there be DevOps · e.g., OpenStack Horizon CLI e.g., OpenStack CLI Config. management e.g.,...
CI is the answer, isn’t it?
IN THE BEGINNINGDEVELOPMENT AND OPERATIONS WERE FUNCTIONAL SILOS
IN THE BEGINNINGDEVELOPMENT AND OPERATIONS WERE FUNCTIONAL SILOS
Miguel Jiménez, Hausi MüllerVictoria, Canada
{miguel, hausi}@uvic.ca
Gabriel TamuraCali, Colombia
DevOpsLet there be
Integration
Culture CommunicationDelivery
MeasurementQuality Automation Tools
Improvement
Continuous Software Engineering
• Developers and IT operators work on different environments/artefacts
• Continuous feedback lacks automation to impact software design
• Industry is moving towards eliminating the Ops role, while assigning more responsibilities to developers
• App code != deployment code. The latter is tested by deploying the app
• How can we streamline continuous feedbackto support the continuous development cycle?
• How can we enable autonomic capabilities to provide feedback from run time to design time?
• What kind of automation is needed to facilitate continuous experimentation and architecting?
• How can we assure quality for deployment code beyond static analysis, w/o deploying the system?
What’s missing?State of the Practice
Bidirectional Traceability Continuous Integration (CI)
SoftwareDeployment
Version control repository
CI✘ Management
Tools
ContinuousIntegration
• Where are all these changes logged?• How can they be traced back to their source?• How and when are stakeholders notified about them?
Round-Trip Engineering One Platform To Rule Them All
The Problem
The Solution
NetworkHardwareSoftware
Designe.g., Informal Diagrams, UML
SoftwareDeployment
Deployment Specse.g., TOSCA, OpenStack HOT
DevWeb admin
e.g., OpenStack Horizon
CLIe.g., OpenStack CLI
Config. managemente.g., OpenStack HEAT
Ops
Management Tools
Automatic changese.g., Scaling policies
ACRO
SS S
YSTE
MLA
YERS
Designtime Runtime
Traceability/Feedback from Ops to Dev?
Ops EngineersAutonomicmanagers
Dev Engineers
The infrastructure becomes a proxy to commit runtime actions Considerations
Prag
mat
ic Ap
proa
chCONFLICT RESOLUTION
Reliable vs Best effort• Less prioritized changes
are discarded• Try to merge non-
conflicting changes
CI PRINCIPLES
QA, build, deployment• Automate the build?•Make the build self-testing?
•QA is open challenge• Automate deployment?
CONTRIBUTION MODEL
Committer vs Contributor• No update delay• Less merge conflicts• Unsupervised changes
• Update delay• Time reviewing changes• Frequent merge conflicts Pr
agm
atic
Appr
oach
The Motivation
1. Nugroho, Ariadi, and Michel RV Chaudron. "A survey of the practice of design--code correspondence amongst professional software engineers.". First International Symposium on Empirical Software Engineering and Measurement. IEEE, 2007.
2. Castañeda, Lorena. “Runtime Modelling for Smart User-centric Cyber-Physical-Human Applications”. PhD thesis, 2017
• Specifications are always up to date• Runtime data is fed back to development• This framework enables further sync:• Design ↔ Deployment specs ↔ Running system• Runtime metrics →continuous experimentation specs
Infrastructure.yaml
Network.yaml
Software.yaml
Pull/Push
MART
Operations
Notation
MART Infrastructure
Instance-Specification TranslatorPull/Push
RUNTIME SUPPORT [2]
APIse.g., Neutron
Web admine.g., OpenStack Horizon
CLIe.g., OpenStack CLI
Config. managemente.g., OpenStack HEAT
Automatic changese.g., Scaling policies
Ops Engineers
Autonomicmanagers
Dev Engineers
Ops Engineers
Version control repository
Systematic approaches to maintain the correspondence between design and code are rarely used in practice [1]
REFERENCES
Benefits