Transcript Project Proposal Open-O Parent - the OPEN

Open-O Integration
Project Introduction
Integration F2F @ Shanghai
August 29, 2016
Goals
• Provide all the common and cross-project
infrastructure code, setup, processes, etc.
– Avoid duplication of effort
– Make project teams’ lives easier
– “We take care of things so you don’t have to”
• We are here to help you
Roles
• “We”: the Integration project team
• “You”: all Open-O project teams and contributors
• Each Integration committer has two roles
– Integration team member
• Help Integration project provide services to others
– Representative of another project
• Act as liason to convey project-specific requirements, updates, etc.
Overview
• What services will Integration provide?
• How do projects leverage these services?
What Integration Will Provide – Release 1
• O-Parent
– Shared common defaults
• CI-Management
– Jenkins Job Definitions
• Test
– Automation of unit and system test flows
• Autorelease
– Builds all projects from scratch / cross-project dependency validation
• Distribution
– End-user scripts, config files, README
• POC
– Scripts for setting up POC sample deployment
Tool Infrastructure
Contribution
Activity Reports
(Bitergia or
Spectrometer)
Code / Unit Test
Repository
(Git/Gerrit)
System Test
Repository
(Git/Gerrit)
Artifact
Repository
(Nexus)
Build / Unit Test
(Jenkins, Maven)
System Test
(Robot
Framework)
API
Documentation
(Swagger)
Unit Test
Code Coverage
Reports
(SonarQube)
System /
Performance
Test Reports
(Robot, JMeter)
O-Parent
• License check
– Apache License Version 2
• Nexus setup
– POM <distributionManagement> tag
• Checkstyle
– Google Java Style Guide
• Static code analysis
– E.g. FindBugs
License Check
• Apache License Version 2
• Mandatory
– Build fails if license header is missing
• Sample header text
– oparent/license/doc
Checkstyle
• Consistent code style
– Simplifies code reviews and version comparisons
– Eases code contribution into multiple projects
• Non-Mandatory
– Style violations reported as warnings
– Build will not fail when there are style violations
– Projects encouraged to minimize style warnings
Google Java Style Guide
• Well-known and well-documented
– https://google.github.io/styleguide/javaguide.html
– Saves us from writing our own style document
• Excellent tooling support
– Built-in support in Checkstyle tool
– IDEs (Eclipse, IntelliJ, etc.)
– Command-line formatter
CI-Management (Jenkins)
Periodic (Daily)
Per Patch
Patch
Submission
All Projects
Build From
Source
Patch Merge
Deploy to
Nexus
Single Project
Build /
Core Unit Tests
Check
Cross-Project
Dependencies
Single Project
Build /
Core Unit Tests
Deploy to
Swagger
Deploy to
SonarQube
All Projects
Build From
Artifacts
ProjectDependent
System Tests
All Unit Tests
All System Tests
Jenkins JJB Job Types
• Verify (patch submission)
– Build project and run unit tests (mvn clean install)
– Check for cross-project dependency issues (e.g.
circular/unsatisfied dependencies)
• Merge (patch merge)
– Deploy project SNAPSHOT artifacts to Nexus (mvn deploy)
– Run project-dependent system test suites
• Periodic (daily)
– Run full, clean build of all projects from source
– Run all unit tests and system test suites
Unit Tests
•
•
•
•
•
•
•
Single project
Feature/function tests
Tests at the class/method level (JUnit)
Tests using mock servers/APIs or stubs
Source controlled in each project’s own repo
Run with Maven
Core vs. Comprehensive
– Core: run at every patch submission/merge
– Comprehensive: run on periodic basis (e.g. daily)
System Tests
• Cross project
• Performance tests
– E.g. latency, throughput, longevity, scalability
•
•
•
•
Tests using live servers, VMs, containers
Source controlled in Integration project repo
Run with Robot Framework
Project-Dependent vs. All Tests
– Project-Dependent: run at patch merge
– All Tests: run on periodic basis (e.g. daily)
System Test Suite Repository
• Source controlled in:
– integration/test/csit/suites/{project}
• Each project
– May have multiple test suites
• Divided into functional areas
– Specifies its upstream project dependencies
• Project-Dependent test suites
– all test suites marked as dependent on a project
– E.g. if GS-O is dependent on NFV-O, then GS-O test suites are
run when NFV-O is changed
How to Leverage Integration’s Services, Part 1
• Use provided Jenkins JJB templates
– Found in ci-management/jjb
– {project}-verify-java
– {project}-merge-java
• Project structure
– Inherit from O-Parent
– Define Top-Level POM
• If the repo contains only a single top level directory, consider moving
its contents to the root
How to Leverage Integration’s Services, Part 2
• Set up ~/.m2/settings.xml
– Allows pulling artifacts from Open-O’s Nexus server
– Get sample copy from oparent/settings.xml
• Make Java source code compliant
– Add Apache License Version 2 header
– Format Java source code into Google Java Style
• https://github.com/google/google-java-format
– Use Google Java Style formatters for IDEs
• Consider auto-formatting on save
How to Leverage Integration’s Services, Part 3
• Organize unit tests
– Core: critical feature/function tests
– Comprehensive: tests that are time-consuming
• System test suites
– Guidelines TBD
• Swagger API Documentation
– Guidelines TBD
How to Leverage Integration’s Services, Part 4
• Provide build / deployment requirements
– RAM requirements, Linux version, Java version, etc.
– Configuration files used
– How to run each module
How to Leverage Integration’s Services, Part 5
• Avoid re-inventing the wheel / duplicating effort
– If the defaults don’t work for you, talk to us
– Ideas that may be useful for all projects are always welcome
– Help us help you! If anything can be done in a better way,
just ask
Thank You for Your Contribution
• We are here to help
• We also need your help
• Let’s work together to make Open-O successful!
Q&A
• Q&A
• Integration mailing list
– http://lists.open-o.org/mailman/listinfo/openo-integration