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

“We”: the Integration project team 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 Code / Unit Test Repository (Git/Gerrit) System Test Repository (Git/Gerrit) Artifact Repository (Nexus) Build / Unit Test (Jenkins, Maven) System Test (Robot Framework) Contribution Activity Reports (Bitergia or Spectrometer) API Documentation (Swagger) Unit Test Code Coverage Reports (SonarQube) System / Performance Test Reports (Robot, JMeter)

O-Parent License check Nexus setup Checkstyle Static code analysis Apache License Version 2 Nexus setup POM <distributionManagement> tag Checkstyle Google Java Style Guide Static code analysis E.g. FindBugs

Apache License Version 2 Mandatory Sample header text License Check Apache License Version 2 Mandatory Build fails if license header is missing Sample header text oparent/license/doc

Checkstyle Consistent code style Non-Mandatory 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) Per Patch Periodic (Daily) Patch Submission Patch Merge All Projects Build From Source Deploy to Nexus Single Project Build / Core Unit Tests Single Project Build / Core Unit Tests All Unit Tests All Projects Build From Artifacts Check Cross-Project Dependencies Deploy to Swagger Deploy to SonarQube Project-Dependent System Tests All System Tests

Jenkins JJB Job Types Verify (patch submission) Merge (patch merge) 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

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!

Integration mailing list Q&A Q&A Integration mailing list http://lists.open-o.org/mailman/listinfo/openo-integration